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EXECUTIVE  SUMMARY 

This  study  addresses  the  Acquisition  Management  System  within  the 
Department  of  the  Navy,  with  particular  emphasis  on  determining  the 
detailed  steps  leading  up  to  the  Program  Initiation  decision.  Speci- 
fically, given  the  operational  need,  how  does  one  go  about  requesting 
initiation  of  a new  systems  program  to  meet  the  operational  need?  What 
are  the  formal  procedures,  documentation  and  approvals  required?  How 
does  one  break  into  the  budget  cycle?  What  are  the  detailed  activities 
and  outputs  of  the  Concept  Formulation  Phase?  What  are  some  of  the 
pitfalls  that  the  Program  Manager  may  encounter  along  the  way  to  the 
Program  Initiation  decision?  These  are  the  areas  addressed  in  the  study 

Section  2 provides  an  overview  of  the  systems  acquisition  process 
in  the  Department  of  Defense  and  the  Department  of  the  Navy.  Special 
attention  is  given  to  identifying  the  required  procedures,  documentation 
and  approval  cycles  that  are  required  at  each  level  in  the  bureacracy. 
Obtaining  funds  for  a new  program  is  also  considered.  The  Planning, 
Programming  and  Budgeting  System  (PPBS)  and  the  DCP/DSARC  Process  are 
discussed,  and  the  importance  of  being  attuned  to  the  "system"  is 
stressed. 

Some  of  the  key  activities  that  must  be  accomplished  during  Concept 
Formulation  are  discussed  in  section  3.  Attention  is  given  to  key 
decision-making  documentation  (i.e.,  DP,  NDCP  and  DCP)  and  the  detailed 
information  that  must  be  developed  in  support  of  DSARC  I.  Section  4 
provides  a detailed  account  of  the  events  leading  up  to  the  Program 
Initiation  decision  by  the  SECDEF,  highlighting  the  DCP  coordination  at 
all  levels  in  preparation  for  DSARC  I. 
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Some  potential  problem  areas  are  identified  in  section  5.  Speci- 

$ 

fically,  the  problem  areas  discussed  are  related  to  four  areas, 
namely:  (1)  Organizational  size  and  complexity,  (2)  Funding  Considerations 

(3)  Concept  Formulation  authorization  and  funding,  (4)  preparation 
for  DSARC  I. 

Finally,  section  6 provides  some  conclusions  and  recommendations. 
Briefly,  these  are  as  follows: 

(1)  To  counter  potential  communication  breakdowns  due 

to  layering  effects,  one  must  develop  good  informal  working  relations 
with  the  Laboratories,  SYSCOMS,  NAVMAT  and  OPNAV  at  all  levels. 

(2)  It  is  mandatory  that  anyone  concerned  with  the 
initiation  of  a new  program  be  attuned  to  the  "system",  with  special 
emphasis  on  the  PPBS  and  the.  DCP/DSARC  Process. 

(3)  Due  to  inherent  delays  in  the  PPBS  cycle  new  program 
funding  requirements  should  be  submitted  in  the  PCM  at  least  29 
months  before  the  money  is  actually  needed  for  obligation. 

(4)  The  "homework"  necessary  for  DSARC  I must  be  done 
during  the  Concept  Formulation  Phase.  Alternatives  considered  must 
Include  foreign  systems  and  modifications  to  existing  systems. 

(5)  Make  the  DCP  thresholds  challenging  but  attainable. 

(6)  Pre-DSARC  I briefings,  if  properly  handled,  can  lay 
the  ground  work  for  a smooth  DSARC  I meeting. 
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1.  Introduction 


1.1  Purpose . The  purpose  of  this  Individual  Study  Project  is  to  help 
the  author  understand  the  detailed  steps  leading  up  to  "the  formal  authori- 
zation of  a new  major*  systems  program  within  the  Navy.  The  author  was 

2 

motivated  to  select  this  particular  topic  by  his  current  job  assignment , 
which  is  concerned  with  the  initiation  of  a new  systems  program.  Hopefully, 
the  author  will  obtain  enough  information  from  this  study  to  help  take 

3 

this  new  systems  program  through  DSARC  I . While  the  author's  primary 
purpose  is  related  to  a specific  program,  the  information  developed  is 
general  and  the  study  results  should  therefore  be  helpful  to  others  involved 
in  a program  initiation  effort. 

1.2  Background.  Getting  a new  systems  program  started  is  not  easy. 
Historically,  there  has  been  great  reluctance  in  the  Navy  to  solve  fleet 
problems  by  developing  new  systems  - at  least  in  the  author's  experience. 

The  tendency  has  been  to  give  highest  priority  to  "patching- up"  existing 
systems,  even  though  technological  obsolescence  in  such  systems  assures 
ineffectiveness  of  the  result.  In  such  cases,  "real"  solutions  would  lie 
in  the  development  of  new  systems,  using  the  latest  technology — but, 
invariably  the  scarce  money  resources  are  eaten  up  by  the  "patch-up"  approaches. 


*A  major  program  is  defined  by  DODD  5000.1  as  one  which  meets  one  or 
more  of  the  following  criteria:  (1)  Estimated  RDT&E  costs  in  excess  of  50 

million  dollars  or  estimated  production  costs  in  excess  of  200  million 
dollars  (all  in  FY  72  dollars);  (2)  national  urgency;  (3)  recommendation  by 
D0D  Component  Heads  or  Office  of  the  Secretary  of  Defense  (OSD)  officials. 

^The  author  is  with  the  Radar  Systems  Branch  of  the  Naval  Ship  Engineering 
Center  and  is  currently  assigned  to  the  Shipboard  Surveillance  Radar 
Systems  (SSURADS)  Program. 

There  are  three  major  reviews  by  the  Defense  Systems  Acquisition  Review 
Council  (DSARC)  during  the  development  of  a major  Defense  system.  The 
first,  DSARC  I,  addresses  Program  Initiation;  the  second,  DSARC  II,  addresses 
transition  to  Full-Scale  Development;  and  the  third,  DSARC  III,  addresses 
transition  to  Production. 
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The  dilemma  of  this  situation  is  that  the  technology  base  exists  to  solve 
many  of  the  fleet's  problems;  but,  there  does  not  seem  to  be  an  effective 
means  for  planning  and  initiating  orderly,- longer-term  development  programs 
to  use  this  technology  in  new  system  applications.  In  other  words,  the 
problem  is  not  so  much  a technical  one  as  it  is  one  of  management . 

The  issuance  of  SECNAV  Instruction  5000.1,  OPNAV  Instruction  5000.42  . 

and  NAVMAT  Instruction  5000.22,  in  the  author's  opinion,  takes  a giant 

step  in  the  right  direction  in  providing  a solution  to  this  management 

problem.  On  the  surface,  these  instructions  appear  to  streamline  the  Navy 
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systems  planning  and  selection  process  compared  to  the  old  procedures 
(i.e.  the  OR,  DP,  NDCP , DCP  cycle  replaces  the  old  GOR,  TS0R,  PTA,  ADO,  SOR, 
TDP  morass)-*.  However,  it  has  been  the  author's  experience  that  there  is 
considerable  difference  of  opinion  at  various  levels  in  the  System  Commands 
(SYSC0MS),  the  Naval  Material  Command  (NAVMAT)  and  the  Office  of  the  Chief 
of  Naval  Operations  (OPNAV)  as  to  just  what  constitutes  adequate  documen- 
tation, procedures,  approval  cycles  and  funding  according  to  the  new  system. 
Many  of  these  problems,  admittedly,  may  be  "growing- pains" — symptomatic 
of  making  an  adjustment  to  the  new  system  — but  many  have  political  over- 
tones and  some  are  due  to  "die- hard' bureaucrats  who  do  not  want  to  let 
go  of  the  "old  way". 

1.3  Scope.  To  put  the  study  in  perspective,  then,  the  author  is  trying 
to  take  a look  at  the  Program  Initiation  process  from  the  "bottcm-up". 


Readers  interested  in  a concise  summary  of  the  old  system  are  referred 
to  Appendix  J of  reference  (1)  or  pp  3-7  of  reference  (2)  in  the  Bibliography. 

^The  reader  is  referred  to  the  list  of  acronyms  at  the  beginning  of 
the  report. 


* 

That  is,  given  the  operational  need,  knowing  the  deficiencies  in  existing 
equipment  and  having  the  technology  at  hand,  how  does  one  go  about 
requesting  initiation  of  a new  systems  program  to  meet  the  operational  need? 
What  ‘formal  procedures,  documentation  and  approvals  are  needed?  How  does 
one  break  into  the  budget  cycle?  These  are  the  main  areas  that  will  be 
addressed  in  the  study. 

1.4  Organization.  The  structure  of  the  remainder  of  this  report  is  now 
briefly  summarized.  Section  2 provides  an  overview  of  the  systems  acquisi- 
tion process  within  the  Department  of  Defense  (DOD)  and  the  Department  of 
the  Navy  (DN)  with  emphasis  on  those  aspects  which  lead  up  to  the  Program 
Initiation  decision  by  the  Secretary  of  Defense  (SECDEF) . The  material  in 
section  2 is  based  on  a survey  of  DOD/NAVY  directives  and  instructions. 
Special  attention  is  given  to  the  required  procedures,  documentation  and 
approval  cycles  at  each  level  in  the  bureacracy.  Obtaining  funding  for  a 
new  program  is  also  given  some  attention.  Then,  section  3 describes  the  main 
activities  that  occur  during  the  Concept  Formulation  Phase  in  preparation 
for  DSARC  I.  Section  4 briefly  describes  the  coordination  required  for 
DSARC  I and  the  SECDEF  Program  Initiation  decision.  Section  5 discusses 
potential  problem  areas  and  finally,  section  6 provides  conclusions  and 


recommendations . 


2.  An  Overview  of  the  Systems  Acquisition  Process 

When  undertaking  a new  program  initiation  effort  one  must  be  attuned 
to  the  DOD/Navy  acquisition  system  environment,  with  its  mass  of  direc- 
tives, instructions  and  approval  cycles  at  each  organizational  level.  In 
short,  one  must  work  within  the  "system".  This  section  provides  an 
overview  of  DOD/Navy  acquisition  process  for  major  defense  programs. 

A summary  of  the  systems  acquisition  process  is  illustrated  in  figure 
2-1.  The  Director  of  Defense  Research  and  Engineering  (DDR&E)  has  divided 
the  Research  and  Development  (R&D)  portion  of  the  system  acquisition 
process  into  two  groups  (2:  1-1  to  1-15)  . Group  I programs  include  those 
R&D  efforts  up  to  DSARC  II  and  have  as  their  primary  objective  the  creation 
and  demonstration  of  system  options,  which  may  be  useful  for  future 
military  capabilities.  Group  II  programs  are  concerned  with  the  full- 
scale  development  of  selected  options  for  potential  deployment.  These  two 
R&D  groups  are  indicated  in  figure  2-1.  A sharp  management  line  is  drawn 
between  Group  I and  Group  II  programs  since  the  full-scale  development 
decision  requires  commitment  of  much  larger  resources  than  required  by  the 
Group  I programs . 

Referring  to  figure  2-1,  Group  I Programs  include  the  development 
of  a technology  base,  system  alternatives  and  demonstration  of  the  system 
alternatives.  Evaluation  of  the  technology  base  is  of  a continuing 
nature  and  is  unconstrained  by  specific  system  applications.  The  tech- 
nology base  evolves  primarily  from  Research  (6.1)  programs  and  Exploratory 


This  notation  will  be  used  throughout  the  report  for  sources  of 
quotation  and  major  references.  The  first  number  is  the  source  listed  in 
the  Bibliography;  the  following  numbers  are  the  pages  in  the  reference. 
When  the  entire  source  is  referenced  in  general,  only  the  first  number  is 
used.  Thus,  the  notation  (2:  I- 1 to  1-15)  means  reference  (2),  pages 
1-1  to  1-15. 
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Development  (6.2)  programs.  Research  programs  are  aimed  at  developing 
a fundamental  knowledge  base  in  particular  fields,  related  to  long-term 
national  security  needs,  for  application  to  solution  of  particular 
military  problems.  Making  use  of  the  knowledge  generated  by  the  Research 
efforts,  Exploratory  Development  programs  are  directed  toward  establish-  . 
ing  a technology  base  by  developing  and  evaluating  the  feasibility  and 
practicability  of  proposed  solutions  to  specific  military  problems,  short 
of  major  development  projects.  Exploratory  Development  programs  can 
vary  from  fundamental  applied  research  to  breadboard  hardware,  including 
studies,  investigations  and  minor  development  effort.  Both  Research  and 
Exploratory  Development  programs  are  characterized  by  high-risk  and  low- 
cost  expenditures  for  a particular  project.  A successful  project,  how- 
ever, can  have  large  payoffs,  perhaps  leading  to  technical  "breakthroughs" 
in  particular  areas.  The  total  number  of  Research  and  Exploratory  Deve- 
lopment projects  is  large  (typically  in  the  thousands)  and  often  there  is 
intentional  redundancy  between  many  of  the  projects  (e.g.  two  or  more 
scientists  working  on  the  same  basic  problem  to  get  the  benefit  of  diffe- 
rent approaches).  Appendix  A summarizes  the  structure  of  the  Navy's 
Research  and  Exploratory  Development  Programs. 

The  next  step  in  the  system  acquisition  process  is  to  draw  upon  the 
.technology  base  in  formulating  system  concepts  which  are  directed  toward 
satisfying  particular  operational  needs.  This  leads  to  the  Concept  Formu- 
lation phase.  Usually,  there  will  be  some  overlap  of  Exploratory  Develop- 
ment (6.2)  and  Advanced  Development  (6.3)  in  the  conceptual  phase.  It  is 
during  this  phase  of  the  acquisition  process  that  the  R&D  effort  becomes 
system- oriented.  The  beginning  of  the  Concept  Formulation  phase  starts 


with  the  establishment  of  a definite  operational  need.  In  the  Navy  this 
occurs  when  the  Office  of  the  Chief  of  Naval  Operation's  (OPNAV)  issues  an 
Operational  Requirement  (OR)  document.  The  duration  of  the  Concept  Formu- 
lation phase  can  vary  from  about  six  months  to  several  years  (or  more) 
depending  on  the  particular  program  situation,  whereas  the  time  required  to 
develop  the  technology  base  can  be  as  much  as  ten  years  (or  more)  before  a 
particular  technology  finds  system  application. 

The  conceptual  effort  results  in  the  definition  of  alternative  system 
concepts  for  providing  a particular  operational  capability.  At  this  point 
a formal  request  is  made  via  the  Defense  Systems  Acquisition  Review  Council 
(DSARC)  for  initiation  of  an  advanced  development  validation  phase.  This 
review  is  called  the  DSARC  I milestone.  Approval  of  the  transition  to  a 
validation  phase  constitutes  formal  authorization  for  Program  Initiation. 

The  Advanced  Development  (6.3)  phase  is  then  directed  toward  develop- 
ing and  testing  particular  system  hardware  in  the  high-risk  areas  to  vali- 
date particular  alternatives  (normally  at  least  two  alternatives  are  carried 
through  validation).  In  some  cases,  full  alternative  systems  may  be  proto- 
typed and  tested  during  the  validation  phase,  depending  on  the  size  and 
expense  involved.  More  typically,  one  could  expect  prototyping  and  testing 
- of  just  the  risky  portions  of  alternative  systems  (rather  than  the  whole 
system)  while  other  system  aspects  might  be  validated  by  detailed  analyses 
and/or  simulations.  The  output  of  the  validation  phase  would  be  the  selec- 
tion of  a preferred  system  approach  (usually  one)  for  full-scale  development. 

The  development  up  to  DSARC  II  has  been  directed  at  creating  and 
demonstrating  system  options  (i.e.  Group  I programs)  with  the  recommenda- 
tion of  alternative  system  solutions  for  an  operational  need.  DSARC  II  is 
a critical  milestone,  which  will  determine  whether  or  not  the  program 
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proceeds  to  full-scale  development.  Authorization  of  the  full-scale 
development  phase  would  transition  the  program  to  a Group  II  program, 
whidh  is  aimed  at  full-scale  development  of  a system  for  potential 
deployment.  Of  course,  much  larger  sums  of  money  are  now  involved, 
hence  the  rigorous  program  scrutinization  up  to  the  SECDEF  level . 

After  successful  full-scale  development  and  Operational  Test  and 
Evaluation  (OT&E),  a production  decision  will  be  made  via  DSARC  III 
followed  by  deployment  of  the  system  in  the  fleet.  The  operational  deploy- 
ment of  a system  can  be  20  years  or  more  while  the  full-scale  development, 
OT&E  and  initial  production  may  take  as  much  as  10-12  years  from  the  time 
of  the  initial  system  concept. 

How  does  a program  manager  break  into  the  system  acquisition  process 
just  described?  First , it  must  be  recognized  that  there  are  two  comple- 
mentary management  processes  (3:  III- 10)  superimposed  on  the  DOD  Acqui- 
sition System  just  described.  These  form  a continuum  of  activity,  with 
which  the  Program  Manager  must  be  attuned.  These  are:  (1)  The  Planning, 
Programming  and  Budgeting  System,  (2)  The  DCP/DSARC  Process.  The  Planning, 
Programming  and  Budgeting  System  (PPBS)  is  primarily  fiscally  oriented; 
that  is,  with  getting  money  into  the  budget  to  support  approved  programs. 
The  DCP/DSARC  Process  is  primarily  a program- oriented  SECDEF  decision- 
making process.  It  provides  a vehicle  for  SECDEF  approval  (or  disapproval) 
of  proposed  new  major  programs  and/or  review  of  existing  major  programs 
at  critical  milestones.  Each  of  these  processes  is  briefly  discussed 
in  sections  2.1  and  2.2.  Then,  section  2.3  describes  the  system  acqui- 
sition process  in  the  Department  of  the  Navy. 
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2.1  The  Planning,  Programming  and  Budgeting  System 
The  Planning,  Programming  and  Budgeting  System  (PPBS)  in  the  Depart- 
ment of  Defense  (3:6-9^  is  the  process  through  which  the  SECDEF  admini- 
stratively controls  the  military  departments  and  defense  agencies.  It  is 
through  the  PPBS  that  the  SECDEF  provides  policy  and  guidance  on  force 
levels,  manpower  and  fiscal  constraints,  issues  decisions  regarding 
program  goals  to  support  the  forces  and  budgets  annual  funds  to  support 
the  programs.  The  main  products  of  the  PPBS  process  are  the  Five-Year 
Defense  Plan  (FYDP)  and  the  annual  budget.  The  FYDP  is  the  official  program 
of  the  DOD;  it  summarizes  the  approved  five-year  programs  of  all  military 
departments  and  defense  agencies.  It  is  a viable  plan  which  is  updated 
three  times  a year  as  changes  occur  in  accordance  with  the  PPBS  cycle. 

The  FYDP  projects  manpower  and  material  fiscal  requirements  for  five- years 
and  force  levels  for  eight  years. 

The  FYDP  is  fiscally  oriented.  It  is  not  the  vehicle  through  which 
the  merits  of  new  programs  are  judged.  It  is  primarily  concerned  with 
balancing  all  approved  programs  within  the  financial  constraints  provided 
by  the  SECDEF.  The  Department  of  the  Navy  Program  Objectives  Memorandum 
(POM)  is  the  vehicle  by  which  the  Secretary  of  the  Navy  proposes  revisions 
to  the  approved  programs  in  the  FYDP.  Because  of  the  cyclic  nature  of 
the  PPBS  and  the  overlapping  of  the  planning,  programming  and  budgeting 
phases  it  takes  approximately  21  months  to  get  a new  program  into  the 
budget , 

Figure  2-2  illustrates  the  overlap  in  the  PPBS  phases  for  any  given 
o 

For  a more  complete  description  of  the  PPBS  process,  the  reader  is 
referred  to  references  (3),  (4)  and  (18)  in  the  Bibliography. 
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fiscal  year  and  points  out  the  reason  for  the  21  month  delay  in  enter- 
ing, a new  program  into  the  President's  budget.  Note  that  in  any  current 
fiscal  year  there  are  three  budget  activities  that  take  place  (4:7) > 
(18:35).  First,  the  current  fiscal  year  budget  is  being  executed. 

Second,  the  budget  for  the  "budget  year"  (i.e.  the  current  fiscal  year 
plus  one)  is  reviewed  at  Service  headquarters  and  SECDEF  levels  during 
the  first  quarter  of  the  current  fiscal  year  and  is  submitted  to  the 
President  for  inclusion  in  his  budget  in  January.  The  President's 
budget  is  then  submitted  to  Congress  for  enactment  for  the  next  fiscal 
year  (i.e.  the  budget  year).  Third,  during  the  current  fiscal  year, 
programming  and  shaping  of  the  budget  for  the  "programming  year"  (i.e. 
current  fiscal  year  plus  two)  takes  place  as  indicated  in  figure  2-2. 
Finally,,  planning  is  done  for, the  current  year  plus  two  and  beyond. 

Indicated  in  figure  2-2  is  a time  delay  of  21  months  from  entering 
the  planning  cycle  until  the  President's  budget  is  submitted  to  Congress. 
It  takes  an  additional  8 months  for  Congress, "to  enact  the  budget.  So, 

the  minimum  time  delay  in  obtaining  funds  for  a given  program  is  about 

3 

29  months.  This  time  delay  emphasizes  the  importance  of  the  Program 
Manager  attuning  himself  to  the  PPBS  cycle  and  providing  POM  inputs  as 
early  as  possible  to  establish  a "line- item"  in  the  FYDP. 

2.2  The  DCP/DSARC  Process 

The  DCP/DSARC  process  (3:111-10,11)  is  the  means  by  which  the 

^Since  the  budget  for  the  "programming  year"  rapidly  firms  up  during 
the  current  year,  the  Program  Manager  must  be  particularly  astute  or  he 
may  become  "locked- out"  of  the  budget  for  an  additional  year  - thereby 
increasing  the  29  month  delay  to  41  months  or  more. 


BUDGET  YEAR  I PROGRAMMING  YEAR 


4 

SECDEF  reviews  and  makes  decisions  on  individual  major  defense  programs  . 
The  need  for  SECDEF  decisions  on  individual  phases  of  each  major  program 
does  not  always  coincide  with  the  PPBS  events.  In  addition>  the  review 
of  the  POM  (Program  Objectives  Memorandum)  and  budget  submittals  does 
not  always  permit  adequate  SECDEF  review  of  the  progress  of  each  major 
defense  system  program.  The  DCP/DSARC  process  complements  the  PPBS 
by  addressing  issues  related  to  progress  of  individual  defense  system 
programs  and  ensures  SECDEF  reviews  related  primarily  to  the  individual 
program  schedule  rather  than  the  PPBS  schedule.  This  is  particularly 
important  for  recommended  new  programs  which  have  not  yet  made  it  into 
the  PPBS  cycle  as  an  approved  program.  The  DCP  (Decision  Coordinating 
Paper)  is  the  document  by  which  the  DCP/DSARC  process  is  initiated. 

Thus,  there  are  two  basic  documents  through  which  the  Services  can 
make  recommendations  to  the  SECDEF  for  initiation  of  new  major  programs, 
namely  the  POM  and  the  DCP.  Fiscal  requirements  for  a new  program  can 
be  entered  into  the  Service  PCM  during  the  Planning  and  Programming  cycle 
of  the  PPBS.  Even  though  such  a recommended  "new- start"  does  not  become 
an  approved  SECDEF  program  by  this  process,  it  is  still  necessary  to  "line- 
up" funds  prior  to  SECDEF  approval,  because  of  the  21  month  delay  between 
planning  and  budgeting  built  into  the  PPBS  cycle.  The  DCP  is  the  docu- 
ment through  which  the  service  formally  requests  a SECDEF  decision,  through 
the  DSARC,  for  initiation  of  a new  major  system  program.  SECDEF  decisions 
as  a result  of  the  DCP/DSARC  process  are  reflected  in  the  next  update 
of  the  FYDP  in  the  PPBS  cycle. 

^References  (5),  (6)  and  (17)  in  the  Bibliography  describe  the  DCP/ 
DSARC  process  in  detail. 


2.3  System  Acquisition  Within  the  Department  of  the  Navy 

The  basic  document  which  establishes  policy  for  major  system  acqui- 
sitlon  within  the  Department  of  Defense  (DOD)  is  DOD  Directive  5000.1  (1). 
Within  the  Department  of  the  Navy  a hierarchy  of  instructions  implement 
DODD  5000.1,  starting  with  SECNAV  (Secretary  of  the  Navy)  Instruction. 

5000.1  (7),  then  0PNAV  (Office  of  the  Chief  of  Naval  Operations)  Instruc- 
tion 5000.42  (8)  and 'finally  NAVMAT  (Naval  Material  Command)  Instruction 
5000.22  (9).  Basically,  there  is  an  implementing  instruction  for  each 
major  level  of  authority  within  the  bureaucracy. 

Figure  2-3  illustrates,  in  a simplified  form,  the  structuring  of  the 
Department  of  the  Navy  for  acquisition.  The  location  of  Project  Management 
Offices  are  also  indicated  for  NAVMAT-Level  Projects  and  SYSCOM-Level 
Projects.  Note  that,  within  the  department,  there  are  three  major  levels 
of  authority  over  NAVMAT  projects  and  four  levels  over  projects  at  the 
SYSCOM  level.  Each  level  of  authority  Imposes  its  own  procedures  and 
approval  cycles  for  system  acquisition  prior  to  soliciting  higher- level 
approval.  In  addition,  each  approval  level  requires  considerable  coordi- 
nation with  staff  offices.  In  addition  to  this  layering  there  are  further 
levels  of  approval  up  through  the  Department  of  Defense  (DOD)  in  reaching 
the  SECDEF,  which  include  the  Assistant  Secretaries  of  Defense  (ASD's), 
Director  of  Defense  Research  and  Engineering  (DDR&E),  the  Defense  Systems 
Acquisition  Review  Council , associated  staffs  and  advisory  groups.  So, 
the  importance  of  a concise,  uniform  set  of  decision-making  documentation 
is  evident. 

At  the  Secretary  of  the  Navy  level  DODD  5000.1  is  implemented  via 
SECNAV  Instruction  5000.1  which  establishes  policy  and  management  principles 
for  acquisition  of  systems.  At  the  Chief  of  Naval  Operations  (CNO)  level, 
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OPNAV  (Office  of  the  Chief  of  Naval  Operations)  Instruction  5000.42 
entitled  "Weapon  System  Selection  and  Planning",  amplifies  the  policy 
set  forth  in  SECNAV  Instruction  5000.1  and  establishes*  revised  R&D 
(Research  and  Development)  planning  procedures.  Then,  at  the  NAVMAT 
level,  NAVMAT  Instruction  5000.22,  also  entitled  "Weapon  System  Selection 

and  Planning",  amplifies  the  guidance  given  in  OPNAV  Instruction  5000.42 
where  necessary  and  revises  R&D  planning  review  procedures  within  the 

Naval  Material  Command. 

This  hierarchy  of  directives  and  instructions  may  appear,  at  first 
glance,  to  contribute  to  excessive  layering  within  the  Department  of  the 
Navy.  No  doubt,  there  is  layering  as  is  evident  from  figure  2-3,  but  the 
net  result  of  this  new  hierarchy  of  instructions  is  a big  simplification 
(10:3-11,  20)  over  previous  system  acquisition  procedures.  Moreover,  the 
planning  and  decision-making  documents  (i.e*  the  OR,  DP,  NDCP,  DCP)  are 
clearly  defined  and  uniform  at  all  levels  within  the  Navy  bureacracy.  And, 
of  course,  the  DCP  is  the  link  with  higher  authority  decision-making. 

While  approval  is  still  required  at  all  levels  up  through  the  chain-of- 
command,  the  consistent  set  of  decision-making  documents  should  improve 
the  vertical  communication  process. 

Each  of  the  three  Navy  Instructions  (i.e.  SECNAV  Instruction  5000.1, 
OPNAV  Instruction  5000.42  and  NAVMAT  Instruction  5000.22)  is  now  briefly 
discussed,  with  emphasis  on  program  initiation  aspects. 

2.3.1  SECNAV  Instruction  5000.1/System  Acquisition  in  the  Department 
of  the  Navy 

SECNAV  Instruction  5000.1  implements  DODD  5000.1  and  establishes 
policy,  relationships  and  responsibilities  for  acquisition  of  systems 
within  the  Department  of  the  Navy.  It  includes  DODD  5000.1  as  an  enclosure, 


cancels  twenty- eight  existing  Navy  instructions  concerning  systems 
acquisition  and  identified  fifty- six  additional  related  instructions  to 
be  reviewed  for  policy  consistency  and  to  be  revised  and  consolidated 
as  appropriate.  This  review  led  to  promulgation  of  GPNAV  Instruction 
5000.42  and  NAVMAT  Instruction  5000.22,  which  will  be  described  in  sections 
2.3.2  and  2.3.3,  respectively,  and  the  subsequent  cancellation  of  ten 
additional  instructions.  This  reduction  in  number  of  instructions  consi- 
derably streamlined  the  planning  and  decision- making  documentation  within 
the  Department  of  the  Navy. 

Relative  to  Program  Initiation,  SECNAV  Instruction  5000.1  assigns 
responsibility  for  identifying  operational  needs,  determining  characteristics 
and  defining  requirements  to  meet  the  needs  to  the  Chief  of  Naval  Operations 
(CNO).  The  CNO  along  with  the  civilian  executive  assistants  are  responsible 
for  advising  the  Secretary  of  the  Navy  with  respect  to  decisions  relative 

r 

to  initiation  of  major  acquisition  programs.  The  responsibility  for  the 
establishment,  application,  and  execution  of  Program/Project  Management 
within  the  Department  of  the  Navy  is  assigned  to  the  Chief  of  Naval  Material 
(CNM),  under  the  Chief  of  Naval  Operations  (CNO).  Once  the  project  is 
chartered  and  a Project  Manager  is  appointed,  the  Project  manager  is  respon- 
sible for  the  formulation  and  execution  of  plans  for  system  development  and 
' production. 

The  Assistant  Secretary  of  the  Navy  for  Research  and  Development,  ASD 
(R&D),  is  responsible  for  managing  the  RDT&E  appropriation.  In  GPNAV,  the 
Director,  Research  and  Development  (DRDT&E)  is  responsible  via  the  CNO  to 
the  ASN  (R&D)  for  coordinating  the  Department  of  the  Navy  RDT&E  program 
and  the  Navy  portion  of  Program  VI  of  the  Department  of  Defense  Five  Year 
Defense  Program  (FYDP). 
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System  acquisition  programs  are  initiated  either  to  capitalize  upon 
a technological  advancement  in  the  state-of-the-art  and/or  to  respond  to 
user  requirements.  Once  the  conceptual  effort  is  far  enough  along  to 
justify  further  pursuit,  and  OSD  approval  thereof  is  subsequently  required, 
the  program  status  shall  be  reviewed  by  the  CNO  Executive  Board  (CEB) 

(13)^.  Appropriate  recommendations  shall  be  used  in  establishing  the  CNO's 
position  on  program  issues  and  alternatives.  The  CNO  position  shall  be 
reflected  in  the  DCP  and  forwarded  to  the  Secretary  of  the  Navy. 

To  assist  the  Secretary  of  the  Navy  in  his  decision-making  process  a 
Department  of  the  Navy  Systems  Acquisition  Review  Council  (DNSARC)  was 
established  (14).  The  DNSARC  provides  a formal  mechanism  by  which  the  Secre- 
tary of  the  Navy  will  receive  the  counsel  of  his  principal  advisors  prior 
to  making  decisions  concerning  initiation  or  continuation  of  major  weapon 
system  acquisition.  The  membership  of  the  DNSARC  consists  of  the  Secretary 
of  the  Navy,  the  Under  Secretary,  the  Assistant  Secretaries,  the  Chief  of 
Naval  Operations  (CNO)  and  the  Commandant  of  the  Marine  Corps  (CMC).  The 
Vice  Chief  of  Naval  Operations  and  the  Assistant  Commandant  may  substitute 
for  the  CNO  and  CMC,  respectively.  In  the  absence  of  the  Secretary  of  the 
Navy,  the  Under  Secretary  will  chair  the  DNSARC.  The  Director,  Office  of 
Program  Appraisal  shall  act  as  Secretary  to  the  Council.  The  DNSARC  not 
only  provides  counsel  to  the  Secretary  of  the  Navy  prior  to  making  decisions 
concerning  major  system  programs,  but  also  provides  a forum  for  review  of 
major  systems  program  presentations  to  be  made  to  the  Defense  Systems 
Acquisition  Review  Council  (DSARC),  the  Secretary  of  Defense  or  Deputy  Secre- 
tary of  Defense. 

^The  CEB  is  an  advisory  council  to  the  CNO  as  defined  by  OPNAVINST 
5420. 2J. 
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The  DNSARC  process  is  used  to  establish  the  official  Department  of  the 

Navy  position  to  be  taken  at  the  DSARC  (or  OSD)  meeting. 

* 

2.3.2  OPNAV  Instruction  5000.42/Weapon  Systems  Selection  and  Planning 

The  acquisition  policy  set  forth  in  SECNAV  Instruction  5000.1  along 

with  the  establishment  of  the  CNO  Policy  and  Planning  Guidance  (CPPG)^  and 

7 . 

CNO  Program  Analysis  Memoranda  (CP AM)  process  required  a restructuring 
of  the  procedures  and  documentation  for  material  development  and  acquisition 
within  the  Navy.  OPNAV  Instruction  5000.42  establishes  such  new  procedures 
and  documentation  for  R&D  planning,  the  generation  of  operational  require- 
ments and  for  conducting  management  reviews  during  system  acquisition. 

Figure  2-4  illustrates  the  planning  documentation  process  by  which 
R&D  programs  are  defined.  The  CNO  Policy  and  Planning  Guidance  (CPPG) 
Document  interprets  the  Defense  Policy  and  Planning  Guidance  Document,  the 
Joint  Strategic  Objectives  Plans  (JS0P)  and  other  studies  in  terms  of  the 
Navy's  roles  and  missions  in  support  of  National  Defense  Policy.  This 
provides  broad  R&D  planning  guidance  for  a five-year  period  consistent 
with  the  Five-Year  Defense  Plan  (FYDP)  timing.  Another  CNO  document,  the 
Extended  Planning  Guidance  (EPG)  interprets  the  SECDEF's  Extended  Planning 
Annex  (EPA)  in  terms  of  the  Navy  role  and  extends  the  CPPG  planning  guidance 
ten  years  beyond  the  FYDP  (i.e.  15  years  into  the  future).  In  addition,  the 


The  CPPG  is  the  CNO's  interpretation  of  the  SECDEF's  Defense  Policy  and 
Planning  Guidance  (DPPG)  as  it  applies  to  the  Navy,  along  with  the  CNO's 
amplification  of  this  guidance,  his  goals  and  priorities. 

^The  CPAM  is  a decision-making  document  developed  for  the  CNO  by  the 
Systems  Analysis  Division  (OP-96),  which  provides  in-depth  analysis  of 
each  major  mission  and  support  category  and  alternatives  on  how  to  best 
accomplish  the  goals  of  the  CPPG. 
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Force  and  Mission  Sponsors  in  OPNAV  generate  individual  plans  for  their 
areas  (e.g.  Surface,  Subsurface  and  Air  Warfare  Plan)  which  are  consistent 
with  the  CPPG  and  EPG  planning.  The  Force  and  Mission  Sponsor  plans  are 
time- phased  according  to  short,  mid  and  long-range  requirements,  and  fore- 
cast platforms  and  weapon  systems  (modernizations  or  new)  corresponding  to 
those  time  frames.  Finally,  the  Joint  Long  Range  Strategic  Study  (JLRSS) 
and  the  Joint  Research  and  Development  Objectives  Document  (JRDOD)  provide 
additional  R&D  planning  objectives. 

All  of  this  information  is  coordinated  by  the  Director  of  Research, 
Development,  Test  and  Evaluation  (DRDT&E)  in  OPNAV  (OP  098)  and  forms  the 
basis  for  development  of  the  Research  and  Development  (R&D)  Plan  for  the 
Navy.  The  R&D  Plan  consists  of  two  parts; (1)  Science  and  Technology  Objec- 
tives (STO's),  and  (2)  Operational  Requirements  (OR's).  The  STO's  describe 
the  Navy's  needs  and  problems  requiring  R&D  solutions  based  on  the  Navy's 
role  and  operational  situation  10  to  ^0  years  in  the  future.  The  STO's  form 
the  basis  for  definition  of  Research  (6.1)  and  Exploratory  Development  (6.2) 
Programs  which  are  oriented  toward  development  of  a technology  base  and  are 
not  yet  constrained  by  particular  system  applications.  The  Operational 
Requirements  are  the  basis  for  system  acquisition  requiring  R&D  in  the  Advanced 
Development  (6.3)  or  Engineering  Development  (6.4)  categories. 

The  basic  planning  documentation  as  identified  by  5000.42  is  the  OR 
(Operational  Requirement),  the  DP  (Development  Proposal),  the  NDCP  (Navy 
Decision  Coordinating  Paper)  and  the  DCP  (Decision  Coordinating  Paper). 

These  documents  and  the  approval  procedures  form  the  process  by  which  new 
programs  are  started  in  the  Navy.  Figure  2-5  illustrates  the  Program 
Initiation  Frocess  as  defined  in  0PNAVINST  5000.42. 


Referring  to' figure  2-5,  the  process  starts  off  with  the  generation 

of  a "Draft  OR".  There  are  many  ways  for  such  a "Draft  OR"  to  be  developed 

8 * 

but  it  is  beyond  the  scope  of  this  report  to  delve  into  the  details. 

Suffice  it  to  say  here  that  while  OR's  can  originate  entirely  within 
OPNAV,  it  is  not  unusual  for  a Systems  Command  or  fleet  activity  to  propose 
a "DRAFT  OR"  to  OPNAV.  Of  course,  OPNAV  will  review  the  merit  of  such 
proposed  "Draft  OR's"  and  will  only  issue  a final  OR  after  intensive 
internal  review  and  rewriting.  The  main  point  here  is  that  while  suggestions 
are  encouraged  from  all  sources,  OPNAV  is  the  single  authority  that  can 
decide  whether  a valid  operational  need  exists  and  whether  or  not  an  OR  should 
be  issued  to  initiate  the  system  acquisition  process. 

Once  an  OR  is  issued,  the  system  commands  (SYSCOMS)  via  NAVMAT  formally 
respond  with  a Development  Proposal  (DP).  The  DP  presents  a range  of  alterna- 
tive system  concepts,  which  can  possibly  meet  the  operational  requirements, 
and  associated  tradeoffs.  Generation  of  the  DP  will  normally  be  an  iterative 
process  with  informal  dialogue  between  the  developing  agency  and  the  OPNAV 
Sponsor.  Upon  acceptance  of  the  DP  by  the  CNO,.  guidance  is  provided  to 
NAVMAT /SYSCOMS  on  which  alternative  to  pursue.  The  DP  then  becomes  the 
basis  for  a Navy  Decision  Coordinating  Paper  (NDCP).  The  "DRAFT  NDCP"  is 
normally  prepared  by  the  developing  SYSCCM  and  forwarded  via  NAVMAT  to 
OPNAV.  Again  OPNAV  conducts  an  extensive  internal  review  of  the  NDCP,  rewri- 
ting as  necessary.  CNO  approval  of  the  NDCP  constitutes  formal  authority 
to  initiate  the  program  (for  CNO  designated  programs)  or  to  pursue  further 
conceptual  studies  (for  major  programs  requiring  higher  approval  authority). 

In  the  latter  case  in-house  Navy  funding  will  be  provided  to  complete  the 

O 

Readers  interested  in  details  of  how  an  OR  is  generated  are  referred 
to  item  (11)  in  the  Bibliography. 
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conceptual  phase  effort  leading  up  to  DSARC  1.  Ihe  NDCP  then  becomes 
the  basis  for  a DCP  requesting  SECDEF  approval  to  initiate  the  validation 
phase  of  the  program.  The  NDCP  and  DCP  formats  are  the  same.  The  main 
differences  are  the  level  of  approval  needed.  Also,  normally,  for  a 
major  program  the  NDCP  will  be  slanted  toward  the  Conceptual  Phase  while 
the  DCP  will  be  slanted  toward  the  Validation  Phase.  * 

There  are  several  levels  of  program  review  and  approval  required 
within  the  Navy  depending  on  the  level  of  -authority  at  which  the  program  was 
designated.  For  instance,  major  programs  will  be  reviewed  at  the  OPNAV 
level  by  the  CNO  Executive  Board  (CEB)  and  at  the  SECNAV  level  by  the  DNSARC. 
Less  than  major  programs  (i.e.  CNO  Designated),  will  be  reviewed  by  the 
acquisition  Review  Committee  (ARC),  which  is  a sub-panel  of  the  CEB. 

The  DP,  NDCP  and  DCP  documentation  will  be  discussed  further  in  section 
3 of  this  report . 

2.3.3  NAVMAT  Instruction  5000. 22 /Weapon  System  Selection  and  Planning 

NAVMAT  Instruction  5000.22  amplifies  the  guidance  given  in  OPNAVINST 
5000. 42  and  establishes  revised  NAVMAT  R&D  planning  and  review  procedures. 

The  policy  in  5000.22  states  that  the  Deputy  Chief  of  Naval  Material  for 
Development  (CND)  will  take  an  active  part  in  the  project  initiation  for 
major  programs  through  DSARC  I.  However,  the  CND  will  not  impose  reporting 
requirements  more  stringent  then  those  already  required  by  higher  authority. 
The  easing  of  reporting  requirements  is  in  line  with  the  disestablishment 
of  the  Naval  Material  Command  Pre- DSARC  Review  Group  (15).  This  was  done 
with  the  intent  of  minimizing  layering  and  in  recognition  of  the  fact 
that  pre- DSARC  Reviews  would  be  held  at  the  SECNAV  level  with  the  esta- 
blishment of  the  DNSARC  (14).  NAVMAT  does  require,  however,  that  each 
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Project  Manager  scheduled  for  a DSARC  presentation  provide  two  copies 
of  that  presentation  to  the  Deputy  Chief  of  Naval  Material  (Plans  and 
Programs).  Clarifying  information,  if  needed  within  NAVMAT,  will  normally 
be  handled  informally  except:  in  those  instances  where  the  Chief  (or  Vice 
Chief)  of  Naval  Material  specifically  requests  a formal  presentation. 

NAVMATINST  5000.22  provides  some  further  details  of  the  process  by 
which  Development  Proposals  are  generated.  Upon  receipt  of  an  Operational 
Requirement  (OR)  requesting  a Development  Proposal  NAVMAT  will  assign  a 
Principal  Development  Activity  (PDA),  normally  a SYSCOM,  with  the  responsi- 
bility for  undertaking  the  particular  development  effort.  The  PDA  will 
assign  a Development  Proposal  Manager  (DPM),  who  is  responsible  for  coor- 
dinating and  developing  the  DP.  The  time  allowed  to  respond  with  a DP 

is  stated  in  the  NAVMAT  requesting  letter.  This  time  will  vary  according 

q 

to  the  program  - but  60  days  turnaround  is  not  unusual.  NAVMAT  also  requires 
that  an  Environmental  Impact  Statement  be  included  as  part  of  the  DP. 

The  remainder  of  the  instruction  elaborates  on  the  detailed  steps 
shown  in  figure  2-5,  emphasizing  the  NAVMAT  role  in  coordinating  the  DP 
and  expanding  the  process  leading  up  to  the  OR.  Summarizing  the  main  points, 
NAVMAT  emphasizes  the  role  of  the  Exploratory  Development  (6.2)  Program  in 
leading  to  Advanced  System  Concepts  (ASC's)  and  the  logical  transitioning 
of  an  Exploratory  Development  Program  into  Advanced  Development.  This  is 
one  way  that  an  OR  can  possibly  come  into  being  - that  is,  by  evolving 
technology.  The  ASC's  accumulated  from  this  process  are  consolidated  into 
a Navy  Advanced  Concepts  (NAC)  document  which  is  submitted  annually  to  OPNAV 

O 

For  instance,  the  SSUUADS  program  turnaround  time  was  60  days,  but  the 
SIRCS  program  turnaround  lime  to  develop  the  DP  is  about  one  year. 
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by  the  Chief  of  Naval  Development.  The  actual  number  of  these  ASC's  selected 
each  year  from  each  SYSCOM's  recommendations  for  transition  to  Advanced 
Development  is  quite  small.  Usually,  recommendations  for  new  programs  are 
driven  by  Operational  Needs  as  identified  by  OPNAV  rather  than  evolving  from 
ASC  recommendations. 

The  next  two  sections  describe  the  detailed  activities  which  must 
occur  during  the  Concept  Formulation  Effort  leading  up  to  the  Program  Initia- 
tion Decision,  showing  how  the  documentation  requirements  and  procedures 
described  in  this  section  are  applied. 
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3.  The  Concept  Formulation  Phase 

In  the  author's  opinion.  Concept  Formulation  is ‘the  most  important 
phase  of  a major  systems  program.  It  is  in  this  phase  that  operational 
requirements  are  transformed  into  system  performance  requirement-* , 
alternative  system  concepts  are  defined,  tradeoff  analyses  are  conducted 
and  a preferred  system  functional  baseline  starts  to  take  shape.  Con- 
current with  this  effort,  a Project  Manager  is  selected,  the  Project 
Office  is  organized  and  staffed,  the  initial  Project  Master  Plan  is 
developed  and,  in  general,  the  ground  work  is  laid  which  sets  the  course 
for  the  remainder  of  the  program,  DODD  5000.1  states  the  following: 

" — Early  conceptual  effort  is  normally  conducted  at 
the  discretion  of  the  Military  Departments  and  Defense 
Agencies — . It  is  critical  that  the  right  decisions 
be  made  during  this  conceptual  effort;  wrong  deci- 
sions create  problems  not  easily  overcome  later  in 
the  program. " . 

A'  model  of  the  Concept  Formulation  Phase  that  will  be  used  for  dis- 
cussion purposes  throughout  the  remainder  of  this  section  is  provided  in 
Figure  3-1.  This  model  highlights  the  Concept  Formulation  portion  of 
the  System  Acquisition  Process,  identifying  the  Key  activities  and  docu- 
mentation produced  during  this  phase.  Leading  up  to  the  Concept  formula- 
tion Phase,  as  described  in  section  2,  are  activities  associated  with 
the  determination  of  operational  needs  and  the  development  of  a technology 
base.  These  activities  certainly  contribute  to  the  conceptual  effort 
and  could  be  considered  part  of  it.  For  instance,  DODD  5000.1  states: 

" — Underlying  specific  Defense  System  development 
is  the  need  for  a strong  and  usable  technology 
base.  This  base  will  be  maintained  by  conducting 
research  and  advanced  technology  effort  independent 
of  specific  Defense  system  development. — " 
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and,  SECNAV  Instruction  5000.1  states: 

" — Generally,  all  effort  conducted  in  connection 
with  the  user/producer  dialogue  — is  considered 
conceptual  effort  as  the  term  is  used  in  DODD 
5000.1 " 

For  purposes  of  this  study,  the  Concept  Formulation  Phase  is  consi- 
dered to  start  with  the  generation  of  an  Operational  Requirement  (OR) 
issued  by  0PNAV.  At  this  point,  the  conceptual  effort  becomes  systems- 
oriented. 

As  indicated  in  figure  3-1,  the  salient  activities  that  occur  during 
Concept  Formulation  are  categorized  into  three  broad  areas,  as  follows: 

(1)  System  Definition;  (2)  Program  Definition;  and,  (3)  Contract  Defini- 
tion. Effort  in  these  three  areas  proceeds  in  parallel.  The  kev  docu- 
mentation outputs  associated  with  these  three  areas  is  also  indicated 
in  figure  3-1.  The  primary  purpose  of  the  Concept  Formulation  effort  is 
to  define  alternative  system  concepts,  that  satisfy  the  operational 
requirement,  for  presentation  at  the  DSARC  I review.  Consequently,  the 
activities  are  driven  by  (and  matched  to)  the  requirements  for  DSARC  I. 

The  Decision  Coordinating  Paper  (DCP),  which  serves  as  the  basis  for 
DSARC  I,  then,  is  of  paramount  importance.  All  other  output  documentation 
generated  during  the  conceptual  effort  backs  up  the  DCP  and  provides 
detailed  information  for  coordination  at  the  working  level.  The  DCP 
itself  contains  a concise  summary  of  all  the  essential  information  of  the 
program  and  supports  the  decision-making  process  at  the  SECDEF  level. 

Two  other  decision-making  documents  that  are  internal  to  the  Department 
of  the  Navy,  namely  the  DP  and  NDCP,  are  generated  near  the  beginning 
of  the  Concept  Formulation  effort.  The  DP  provides  the  formal  response 
to  the  OR  issued  by  0PNAV,  and,  in  essence,  requests  CN0  authorization 
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and  identification  of  funds  to  conduct  the  conceptual  effort.  This  leads 
to  a Navy  Decision  Coordinating  Paper  (NDCP)  which  formally  authorizes 
the  Concept  Formulation  effort  when  signed  by  the  CNO.  At  this  time 
the  OR  may  be  subsumed  by  the  NDCP . 

The  remainder  of  this  section  describes  in  more  detail  the  activities 
and  documentation  that  occur  during  the  Concept  Formulation  Phase  with 
specific  attention  given  to  the  format  and  content  of  -the  decision-making 
documentation  produced  (i.e.  the  DP,  NDCP  and  DCP). 

3.1  System  Definition 

As  shown  in  figure  3-2,  System  Definition  is  an  iterative  process. 

It  starts  early  in  the  Conceptual  Phase  and  continues  throughout  the 
program.  This  is  not  only  necessary  to  determine  the  system  concept  to 
start  with,  but  to  continually  keep  track  of  the  system  effectiveness  with 
respect  to  the  current  threat,  the  operational  needs  and  current  technology. 
Referring  to  figure  3-2,  the  process  initially  starts  in  response  to 
the  OR  issued  by  OPNAV.  An  initial  assessment  of  the  threat  and  the 
Force  and  Mission  Sponsor's  plans  leads  to  a preliminary  assessment  of 
system  performance  requirements  and  identification  of  a broad  range  of 
alternate  system  concepts  to  satisfy  the  operational  need.  This  informa- 
tion is  used  in  the  preparation  of  the  Development  Proposal  (DP)  response 
to  the  OR  and  later  in  the  preparation  of  the  NDCP  and  the  initial  Project 
Master  Plan.  After  the  CNO  signs  out  the  NDCP,  thereby  authorizing  and 
identifying  funds  for  the  Concept  Formulation  Phase,  the  System  Definition 
is  continued. 

First,  the  threat  and  mission  forecasts  are  updated.  Close  contact 
is  maintained  (19)  with  the  Navy  intelligence  community  (i.e.  Naval 
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Intelligence  Command  (NIC)  and  Naval  Intelligence  Support  Center  (NISC)) 
to  make  certain  that  validated  threat  information  is’  being  used.  Close 
liaison  is  also  maintained  with  the  Force  and  Mission  Sponsors  (e.g. 

Surface  Warfare)  in  OPNAV  to  coordinate  with  their  time- phased  plans 
(i,e.  short,  mid  and  long-range  plans)  concerning  platforms,  weapon 
systems  and  missions.  From  this  updated  information  the  system  performance 
requirements  are  derived.  Then,  alternative  system  concepts  are  defined 
to  meet  the  derived  requirements,  taking  into  account  the  latest  tech- 
nology (from  both  internal  Navy  R&D  programs  and  Industry  IRAD*  programs), 
existing  systems  and  foreign  systems,  "'hat  is,  included  in  the  alter- 
natives considered  are  modifications  to  existing  systems  and  the  possible 
use  of  systems  from  our  foreign  allies,  either  already  existing  or  under 
development.  Only  after  these  alternatives  are  considered,  and  found 
inadequate,  are  r.aw- system  concepts  entertained.  In  developing  alternate 
system  concepts  it  is  important  to  consider  at  this  early  point  ( to  the 
extent  practicable)  the  various  engineering  disciplines  (i.e.  Reliability, 
Maintainability,  Supportability , etc).  Also,  cost  must  be  considered 
as  an  equal  design  parameter  from  the  beginning.  Note  that  as  system 
concepts  arc  defined,  another  look  is  taken  at  the  performance  require- 
ments and  refinements  are  made  in  an  iterative  manner.  Also,  a prelimi- 
nary System  Requirements  Document  is  generated  for  coordination  within 
the  project  at  the  working  level. 

Having  identified  certain  system  concepts  for  consideration,  effec- 
tiveness criteria  are  defined  and  tradeoff  analyses  are  conducted.  Here, 

*The  term  "IRAD"  refers  to  Industry  "Independent  Research  and  Deve- 
lopment" effort. 
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the  use  of  simulations  (either  existing  or  specially  developed)  can 
be  useful  and  maximum  use  is  made  of  historical  data  on  similar  systems 
to  determine  "lessons  learned".  After  effectiveness  analyses  are 
performed,  the  performance  requirements  and  the  alternate  system  concepts 
themselves  are  reexamined  and  further  refined,  as  necessary.  In 
this  iterative  manner,  tradeoffs  are  made  and  a preferred  system  concept 
is  identified.  Critical  risk  areas  are  also  identified  along  with 
fall-back  positions.  This  effort  is  documented  in  detail  in  the  Trade- 
off Studies  Reports.  The  System  Requirements  Document  is  firmed  up 
and  the  preferred  system  concept  is  documented  in  the  System  Functional 
Baseline  Document.  This  information  then  forms  the  basis  for  preparing 
the  Decision  Coordinating  Paper  (DCP),  the  Project  Master  Plan  (PMP) 
and  the  Request  for  Proposal  (RFP)  for  the  Validation  Phase. 

t 

3.2  Contract  Definition 

The  contract  Definition  activity  occurs  in  parallel  with  the  System 
Definition  Process.  In  fact,  the  Concept  Formulation  Phase  itself  may 
involve  contractors.  There  are  some  programs  that  may  contract  out  the 
entire  Concept  Formulation  effort  while  others  may  perform  it  entirely 
in-house.  However,  this  depends  on  the  particular  situation,  the  com- 
plexity of  the  program,  availability  of  in-house  talent,  the  preferences 
of  the  Program  Manager,  availability  of  funding  and  many  other  conside- 
rations . 

The  purpose  of  this  section  is  to  discuss  some  Contract  Definition 

2 

For  example,  the  SSURADS  Program  intends  to  conduct  Concept  Formu- 
lation in-house;  whereas,  the  SIRCS  Program  is  contracting  out  the  entire 
effort . 


activities  that  must  occur  as  part  of  the  Concept  Formulation  Phase  in 
order  to  prepare  for  the  Validation  Phase.  Of  course,  there  may  still 
be  some  support  contractor  involvement,  providing  assistance  in  such 
areas  as  computer  modeling,  effectiveness  analyses,  report  preparation 
and  similar  things.  These  support  contractors,  however,  would  not  be 
involved  in  the  competition  for  the  system  being  procured. 

Early  in  the  Conceptual  Phase  a briefing  for  Industry  would  nor- 
mally be  held.  The  purpose  of  such  a briefing  would  be  to  alert  Industry 
to  the  existence  of  the  program,  define  problem  areas  that  need  solution 
and  provide  tentative  program  planning  information.  Benefits  to  both 
the  government  and  the  contractors  can  result.  For  instance,  contractors 
may  obtain  information  helpful  for  their  annual  business  planning, 
proposal  planning  and  IRAD  project  definition  efforts.  The  government 
can  benefit  by  lining  up  potential  bidders  (thus  establishing  a competitive 
base)  and  by  spinoffs  from  IRAD  efforts  which  may  be  useful  to  the  program. 

Another  primary  activity  would  be  the  definition  of  the  acquisition 
strategy  for  the  Validation  Phase.  While  some  preliminary  work  can  be 
done  in  this  area,  it  is  necessarily  dependent  on  the  outcome  of  the  System 
Definition  Process  and  the  funding  situation.  For  instance,  if  the  pre- 
ferred system  concept  has  a high  degree  of  risk,  it  may  be  desirable  to 
procure  complete  system  prototypes  for  evaluation  during  the  Validation 
Phase.  If  there  are  only  a few  specific  isolated  risk  areas,  perhaps 
only  subsystems  can  be  prototyped  and  evaluated  during  Validation.  Eva- 
luation and  source  selection  criteria  must  be  defined.  Ideally,  a 
competitive  base  of  at  least  two  contractors  is  desirable  for  Validation  - 
but  this  will  largely  depend  on  available  funding.  The  riskiness  of  the 
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approach  will  also  affect  the  type  of  contract  used  for  validation. 

Inputs  from  the  Program  Definition  effort  are  also  required.  Such 
things  as  schedules,  milestones,  Government  Furnished  Equipment,  quan- 
tities, development  and  operational  testing,  logistics  support  requirements 
and  Design- to- Cost  goals  must  be  included  in  the  contract  considerations. 

All  of  the  above  mentioned  items  will  be  incorporated  into  the 
Request  for  Proposal  (RFP).  An  Advanced  Procurement  Plan  (APP)  must 
also  be  prepared  for  the  program  in  accordance  with  Armed  Services 
Procurement  Regulation  (ASPR)  1-2101. 

3.3  Program  Definition 

The  Program  Definition  effort  proceeds  in  parallel  with  and  comple- 
ments the  System  Definition  effort  and  the  Contract  Definition  effort. 

The  main  activities  involved  here  are  associated  with  obtaining  funding, 
the  decision-making  process,  and  detailed  planning  information  for 
organizing  and  coordinating  all  aspects  of  the  program.  The  vehicle  for 
getting  into  the  budget  cycle  is  the  Program  Objectives  Memorandum  (POM) . 
This  was  discussed  in  section  2.1.  The  detailed  planning  information  is 
developed  in  the  Project  Master  Plan  (PMP),  which  is  a viable  document 
(16),  and  will  be  continually  updated  and/or  expanded  as  the  program 
progresses.  Included  as  part  of  the  PMP  will  be  the  Work  Breakdown 
Structure  (WBS),  organizational  relationships,  detailed  task  statements 
and  schedules,  funding  requirements,  the  development  plan,  the  management 
4>lan  and  the  Test  and  Evaluation  Master  Plan  (20),  (21).  Preliminary  DTC 
goals  and  critical  support  requirements  must  also  be  identified  as  early 
as  practicable.  The  decision-making  documentation  (i.e.  the  DP,  NDCP, 

DCP)  is  of  most  interest  in  this  study  and  is  discussed  further  in 
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sections  3.3.1  through  3.3.3.  This  documentation  leads  up  to  DSARC  I 
and  the  Program  Initiation  decision,  which  is  discussed  further  in 
section  4. 

3.3.1  The  Development  Proposal  (DP) 

The  Development  Proposal  is  a summary  document-  limited  to  20  pages. 

It  presents  a range  of  alternatives  and  tradeoffs  for  OPNAV  consideration 
in  response  to  the  OR.  It  is  intended  to  create  dialogue  between  NAVMAT/ 
SYSCCMS  and  the  OPNAV  OR  Sponsor  to  help  converge  on  mutually  agreeable 
recommendations  for  the  Concept  Formulation  phase  of  the  program. 

It  is  important  to  emphasize  the  20  page  limitation,  as  it  points 
out  the  decision-making  role  of  the  document.  Of  course,  many  volumes 
of  detailed  backup  information  may  exist  and  may  be  provided  to  OPNAV  on 
request.  After  OPNAV  approval,  the  DP  serves  as  a basis  for  the  prepara- 
tion of  the  Navy  Decision  Coordinating  Paper  (NDCP).  The  NDCP  is  discussed 
in  section  3.3.2. 

Details  of  the  format  and  content  of  the  DP  are  given  in  OPNAV 
Instruction  5000.42.  A sample  outline  of  the  DP  taken  from  0PNAVINST 
5000.42  is  included  as  Appendix  B of  this  report  for  the  reader's  conveni- 
ence. 

3.3.2  The  Navy  Decision  Coordinating  Paper  (NDCP) 

The  NDCP  is  a document  which  supports  and  promulgates  the  CN0  decision 
to  initiate  the  Concept  Formulation  phase  of  a major  systems  program  in 
response  to  the  DP.  The  NDCP  document  defines  program  issues,  the  consi- 
derations which  support  the  operational  need,  program  objectives,  program 
plans,  performance  parameters,  areas  of  risk  and  development  alternatives 
(8).  Format  and  processing  procedures  within  OPNAV  for  the  NDCP  are 
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similar  to  those  used  for  the  DCP,  which  will  be  discussed  in  section 
3.3/3.  The  main  difference  between  the  NDCP  and  DCP  is  that  the  NDCP 
only  applies^  to  the  Conceptual  Phase  for  a major  program.  The  Concept 
Formulation  effort  then  is  authorized,  funded  and^reviewed  entirely 
within  OPNAV.  When  the  conceptual  effort  has  advanced  far  enough  to 
consider  transition  to  a Validation  Phase j a DCP  is  prepared.  The  NDCP 
serves  as  the  basis  for  the  preparation  of  the  DCP. 

3.3.3  The  Decision  Coordinating  Paper  (DCP) 

The  DCP  supports  the  DSARC  I review  and  the  SECDEF  decision-making 
process.  The  DCP  for  Validation  identifies  the  major  program  issues, 
reestablishes  the  Operational  need,  presents  a range  of  alternative  approa-  J 

ches  (including  modification  of  existing  systems,  use  of  foreign  systems 
and  development  of  new- systems.),  identifies  risk  areas  and  a detailed 
plan  (with  fallback  positions)  for  eliminating  the  risks,  provides  per- 
formance requirements  and  the  detailed  planning  for  the  Validation  Phase 
(including  schedule,  milestones).  Program  thresholds  for  performance,  cost 
and  schedule  are  established  in  the  DCP.  The  DCP,  when  approved,  then 
authorizes  execution  of  the  program  within  the  threshold  limits.  It 
becomes  the  contract  between  the  Secretary  of  Defense  (SECDEF)  and  the 
Navy.  Any  violation  of  the  thresholds  requires  review  and  approval  at 
the  SECDEF  level. 

A check  list  of  the  key  areas  that  must  be  addressed  in  the  Program 
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For  CNO- Designated  programs,  of  course,  the  NDCP  could  authorize 
Validation  or  Full-Scale  Development  phases  of  the  program. 
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Initiation  DCP  is  provided  in  the  Navy  Programming  Manual,  For  the 
coavenience  of  the  reader,  a copy  is  included  as  Appendix  C to  this 
report . 

The  DCP  is  limited  to  20  pages  plus  resource  annexes  for  each  alter- 
native considered.  A suggested  outline  for  the  DCP  is  provided  in  the 
Navy  Programming  Manual.  Again,  for  the  convenience  of  the  readers, 
a copy  is  included  as  Appendix  D to  this  report. 

The  information  in  Appendices  C and  D should  be  useful  to  anyone 


preparing  a DCP. 


4.  The  Program  Initiation  Decision 

The  Concept  Formulation  effort  culminates  in  the  preparation  of  a 

4 

Program  Initiation  Decision  Coordinating  Paper  (DCP  1)  and  a DSARC  I review 
by  which  a SECDEF  decision  is  requested  on  proceeding  into  the  Validation 
Phase  of  the  program.  The  Program  Initiation  DCP  is  the  principal  docu- 
ment which  serves  as  the  basis  for  the  DSARC  1 review  and  the  SECDEF 
decision- making  process.  The  DSARC  serves  as  an  advisory  body  which  makes 
recommendations  to  the  SECDEF  that  are  considered  in  the  formulation  of 
his  decisions  on  major  system  acquisitions.  SECDEF  approval  of (DCP. 1)  consti- 
tutes the  formal  Program  Initiation  decision.  The  DCP,  with  the  thresholds 
(i.e.  for  cost,  schedule  and  performance)  established  therein,  becomes  the 
"contract"  between  the  SECDEF  and  the  Developing  DOD  Component^.  The 
approved  DCP,  then,  establishes  the  limits  of  authority  delegated  to  the 
cognizant  DOD  Component  in  the  conduct  of  the  Validation  Phase  of  the  program. - 

The  remainder  of  this  section  describes  the  detailed  events  leading 
up  to  the  Program  Initiation  decision  by  the  SECDEF.  The  initial  draft 
version  of  the  proposed  DCP  1 is  prepared  by  the  Navy  after  agreement  on 
the  outline  by  the  cognizant  OSD  Staff  Office.  The  OSD  Staff  Office  (for 
Program  Initiation  this  is  ODDR&E)  then  has  the  responsibility  for  coordi- 
nating the  initial  draft  DCP  within  OSD  and  for  collecting  the  comments  of 
each  DSARC  Principal  and  Advisor,  and  from  these  comments  preparing  an 
acceptable  "for- comments"  draft  DCP.  The  "for- comments"  draft  DCP  is  then 
distributed  to  interested  offices  in  OSD  and  to  the  Department  of  the  Navy. 
Based  on  comments  received,  the  DDR&E  coordinator  will  update  the  DCP  as 

*The  term  DOD  Component  refers  to  the  Military  Departments  and  Defense 
Agencies. 


necessary  to  become  the  "for- coordination"  draft  DCP,  which  identifies 
the  issues  surfaced  during  the  "for- comments"  cycle.  The  "for- coordination" 
draft  DCP  then  becomes  the  basis  for  the  DSARC  I review. 

To  illustrate  this  process  further,  as  well  as  the  level  of  intra- 
Navy  staff  coordination  and  approvals  required,  figure  4-1  is  provided. 
Figure  4-1  is  a time  line  of  events  leading  up  to  the  formal  Program 
Initiation  decision.  Note  that  because  of  the  large  amount  of  staff  coor- 
dination required,  the  process  of  preparing  for  DSARC  I- must  start  at 
least  120  days  prior  to  the  scheduled  time.  The  key  people  involved  in 
this  coordination  process  are  the  CPNAV  Program  Sponsor/Coordinator,  the 
NAVMAT  Program  Coordinator  and  the  SYSC0M- level  Program  Manager,  if  one 
has  been  appointed.  However,  at  this  stage  of  the  program  it  is  quite 
likely  that  a Program  Manager  has  not  yet  been  appointed.  In  such  a case 
the  person  directing  the  conceptual  effort  would  most  likely  be  the  program 
representative  for  the  SYSCOM.  Most  of  the  coordination  within  OPNAV  and 
OSD  would  normally  be  handled  by  the  OPNAV  Program  Sponsor/Coordinator 
with  the  support  and  participation  of  the  NAVMAT  and  SYSCOM- level  managers. 

About  130  days  prior  to  DSARC  I,  informal  liaison  is  conducted  between 
the  OPNAV  Program  Sponsor  and  DDR&E  concerning  the  status  of  the  program 
conceptual  effort  and  the  DSARC  I timing.  Part  of  this  liaison  includes 
.proposing  an  outline  for  the  Initial  Draft  DCP.  Referring  to  figure  4-1, 
at  approximately  120  days  prior  to  DSARC  I (i.e.  -120  days  in  fig  4-1) 
a request  is  made  through  the  ASN  (R&D)  to  DDR&E  for  scheduling  a DSARC  I 
meeting.  At  about  the  same  time  written  approval  of  the  Initial  Draft  DCP 
outline  is  obtained  from  DDR&E,  with  identification  of  the  issues  and 
alternatives  to  be  considered.  Then,  at  about  -115  days  the  OPNAV  Program 
Sponsor  requests  supporting  analysis  of  issues  and  alternatives  from  OP-96 
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(Systems  Analysis  Division).  At  the  same  time  the  Project  Manager  (if 
one  exists,  otherwise  the  SYSCOM  Program  Director)  is  coordinating 
assistance  from  other  NAVMAT  elements  as  needed.  Also,'  OP- 098  is  requested 
to  review  the  Test  and  Evaluation  Planning  and  a request  is  made  for  an 
independent  parametric  cost  analysis  from  OP-96D  (Navy  Cost  Analysis  Group) 
at  about  -110  days. 

At  approximately  -90  days,  the  OPNAV  Program  Sponsor  arranges  the 
scheduling  of  all  subsequent  reviews  up  to  DSARC  I.  This  includes  schedu- 
ling of  a PRE-CEB  review  at  approximately  -80  days,  the  CEB  meeting  at  -65 
days,  the  SECNAV  DNSARC  review  at  -30  days  and  SECNAV  level  review  of  the 
DSARC  presentation  at  -10  workdays.  The  Navy  completes  the  Initial  Draft 
DCP  and  distributes  it  internally  to  get  "in-house"  comments  on  issues  and 
alternatives.  This  occurs  at  approximately  -80  days,  about  the  same  time 
as  the  PRE-CEB  review.  About  5 days  prior  to  this  the  OP- 96  analyses 

t 

evaluating  the  issues  and  alternatives,  as  well  as  the  independent  cost 
analyses  are  provided  to  the  OPNAV  Program  Sponsor/Coordinator.  This 
information  along  with  the  Initial  Draft  DCP  will  be  the  basis  for  the  PRE- 
CEB  meeting.  Following  guidance  from  the  PRE-CEB  meeting  and  after  incor- 
porating results  from  the  OP- 96  analyses  as  appropriate,  the  Initial  Draft 
DCP  is  updated  and  serves  as  the  basis  for  presentation  to  the  CEB  at  about 
'”65  days.  At  this  time  the  CN0/CEB  position  on  issues  is  established  and  the 
Navy  Initial  Draft  DCP  is  forwarded  to  DDR&E  at  -60  days  (i.e.  60  days 
prior  to  DSARC) . 

At  this  point  the  cognizant  OSD  office  (i.e.  DDR&E)  is  responsible 
for  review  and  coordination  of  the  Initial  Draft  DCP  with  all  interested 
OSD  offices.  The  DDR&E  staff  will  then  modify  the  Initial  Draft  DCP  as 
appropriate  to  include  OSD  comments.  The  resulting  document  is  then 


4-4 


distributed  as  a "for  comment"  Draft  DCr  to  the  interested  offices, 
including  the  Navy.  This  occurs  at  about  -40  days  in  figure  4-1.  Comments 
are  due  back  to  DDR&E  within  15  days. 

The  "for- comment"  Draft  DCP  is  distributed  within  OPNAV  and  the 
comments  collected  by  the  Program  Sponsor.  Then  the  program  is  reviewed  by 
the  CNO  and  the  CNO  Executive  Board  (CEB)  to  update  the  CNO/CEB  position  orf 
the  current  issues.  This  is  followed  l,  a SECNAV  level  review  via  the 
DNSARC  (Dept,  of  the  Navy  Systems  Acquisition  Review  Council)  review  at  -3C 
days.  The  DNSARC  review  establishes  the  Department  of  the  Navy  (DN) 
position  on  the  proposed  program.  The  DN  position  on  the  "for- comment"  Draft 
DCP  is  forwarded  to  the  DDR&E  coordinator. 

The  DDR&E  coordinator  will  modify  the  "for- comment"  Draft  DCP,  as 
appropriate,  based  on  comments  received.  This  leads  to  the  preparation  of 
a "for- coordination"  Draft  DCP,  which  must  be  available  for  review  by  the 
DSARC  Principals  and  the  Secretary  of  the  Navy  by  at  least  10  days  before 
the  scheduled  DSARC  review.  The  "for- coordination"  Draft  DCP  is  normally 
distributed  by  -20  days.  Again,  the  DN  updates  its  position  relative  to 
the  issues  and  alternatives  identified  in  the  Draft  DCP  and  returns 
comments  to  DDR&E  by  -10  days.  A series  of  briefings  also  occur  at  this 
time  in  preparation  for  the  upcoming  DSARC  I review.  For  instance,  the 
. CEB  reviews  the  planned  DSARC  presentation  at  -15  days.  The  OPNAV  Program 
Sponsor,  assisted  by  the  Project  Manager,  briefs  the  DDR&E  (T&E)  at  -12 
days  and  the  DSARC  presentation  is  reviewed  by  the  ASN  (R&D)  at  - 11  days. 

At  -5  days  the  Program  Sponsor/Coordinator  and  Program  Manager  provide 
OSD  Staff  briefings  as  required  in  final  preparation  for  DSARC  1.  Within 
OSD,  during  the  10  days  before  the  scheduled  DSARC  review,  the  DDR&E  coor- 
dinator is  responsible  for  ensuring  that  copies  of  the  "for- coordination"  draft 
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DCP  get  to  the  DSARC  Principles  and  Advisors.  Also,  the  Chairman  of  the 
Cost  Analysis  Improvement  Group  (CAIG)  is  responsible  for  getting  infor- 
mation on  their  evaluation  of  the  Service  cost  estimates  to  the  DSARC 
Principals  by  -5  days.  And,  the  Deputy  Director  DDR&E  (T&E)  is  responsible 
for  getting  his  Test  and  Evaluation  Report  to  the  DSARC  Principals  by  at 
least  -2  days.  - . • 

After  the  DSARC  1 is  completed,  the  DSARC  chairman  (i.e.  DDR&E)  must 
provide  the  DSARC's  recommendations  to  the  SECDEF  within  15  days.  These 
recommendations  will  include  a clear  and  objective  statement  of  all  issues 
and  a proposed  action  memorandum  for  SECDEF  signature  reflecting  the 
DSARC  recommendations.  Any  dissenting  views  must  also  be  included  in  the 
report.  A copy  of  the  report  is  sent  to  the  Secretary  of  the  Navy  for 
information  and  comment  before  forwarding  to  the  Secretary  of  Defense. 

The  DDR&E  (T&E)  will  also  prepare  an  independent  report  for  the  SECDEF, 
assessing  the  Test  and  Evaluation  situation.  This  report  will  be  attached 
to  the  DSARC  Chairman's  report. 

Once  the  SECDEF  decision  is  made  to  initiate  the  new  program,  the 
DCP  will  be  revised  as  necessary  by  the  DDR&E  staff  to  reflect  the  SECDEF1 s 
decision.  The  resulting  approved  DCP  will  be  issued  within  30  days  after 
the  SECDEF  decision  is  made.  The  SECDEF  decision  will  be  reflected  in  the 
next  update  of  the  FYDP. 
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5.  Discussion  of  Potential  Problem  Areas 
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Section  2 has  provided  an  overview  of  the  System  Acquisition  Process 
within  the  Department  of  Defense,  with  special  emphasis  on  procedures, 
approval  cycles,  and  documentation  requirements  within  the  Department 
of  the  Navy.  Then,  section  3 provided  a detailed  description  of  some 
of  the  key  activities  that  occur  during  the  Concept  Formulation  Phase 
with  emphasis  on  the  key  decision-making  documentation  requirements 
(i.e.  DP,  NDCP  and  DCP) . And,  section  A provided  a detailed  account 
of  the  events  leading  up  to  the  Program  Initiation  decision  by  the  SECDEF, 
highlighting  the  DCP  coordination  at  all  levels  in  preparation  for 
DSARC  I . 

This  section  now  identifies  some  potential  pitfalls  that  the  Program 
Manager  may  encounter  along  the  way  to  the  Program  Initiation  decision. 
Specifically,  potential  problem  areas  are  discussed  as  they  relate  to 
the  following  four  areas:  (1)  Organizational  Size  and  Complexity,  (2) 
Funding  Considerations,  (3)  Concept  Formulation  Authorization  and  Funding, 
(A)  Preparation  for  DSARC  1. 

5.1  Organization  Size  and  Complexity 

System  acquisition  within  the  Department  of  Defense  is  characterized 
by  centralized  policy-making,  with  authorization  and  direction  of 
major  programs  at  critical  phases  (i.e.,  management  by  exception),  and 
decentralized  operation  (i.e.,  the  implementation  of  major  programs  by 
lower- level  managers  within  approved  thresholds  for  cost,  performance  and 
schedule).  Underlying  decentralized  operation  is  the  concept  of  the 
Program  Manager,  with  sufficient  authority  to  accomplish  approved  program 
objectives.  Some  feeling  for  the  complexity  of  the  Acquisition  System 
within  the  Department  of  Defense  and  the  Department  of  the  Navy  is  given 
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in  section  2 of  this  report,  with  directives  identified  for  procedures 
and  approval  cycles  at  each  level  of  the  bureacracy.' 

To  the  author,  the  organizational  layers  and  the  complexity  of  the 
"system"  are  staggering- - yet , the  management  framework  for  effective 
communication  and  decision-making  does  appear  to  exist.-  At  least,  one 
can  determine  how  the  "system"  is  supposed  to  work.  This  is  largely  due 
to  the  Planning,  Programming  and  Budgeting  System  (PPBS)  and  the  DCP/ 
DSARC  Process,  which  are  central  to  the  "system"  and  provide  for  order 
in  the  midst  of  chaos.  The  Program  Manager  must  attune  himself  to  the 
"system".  Operating  within  the  system  will  be  difficult  enough; 
attempting  to  operate  outside  of  the  system  will  assure  failure.  Because 
of  the  size  and  complexity  of  the  Defense  organization  there  are  bound 
to  be  problems  resulting  from  communication  difficulties  and  layering 
effects.  These  problems  can  be  especially  difficult  for  one  trying 
to  initiate  a new  program. 

It  appears  that  the  communication  process  is  one-way,  that  is,  down 
the  chain  of  command.  This  is  typical  of  a directive- oriented  manage- 
ment approach.  The  implication  in  the  "top-down  only"  communication 
is  that  new  programs  can  only  be  started  by  the  initiative  of  the 
highest  echelons.  Indeed,  this  is  one  way  that  programs  can  be  started 
(e.g.,  programs  of  highest  priority  and/or  national  urgency).  In  fact, 
this  is  the  easy  way  to  start  a new  program  (i.e.,  by  direction).  The 
author  believes,  however,  that  it  is  not  the  intent  of  the  "system"  to 

i 

limit  new  starts  in  this  manner.  The  author  believes  that  higher 
echelons  do  want  and  need  recommendations  from  lower  levels  of  management 
(who  are  closer  to  the  problem)  and  expect  communication  up  through 
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the  correct  channels  to  provide  such  recommendations . Unfortunately, 
the  system  complexity  and  organizational  layers  tend  to  breed  pockets 
of  resistance  or  "bureacratic  bottlenecks"  at  various  levels,  which 
cause  the  communication  process  to  break  down.  There  are  just  two 
many  funnels  to  go  through.  Often,  these  "bottlenecks"  will  filter 
out  or  completely  misinterpret  the  information  given  to  them  and, 
consequently,  the  information  never  gets  to  the  higher  levels. 
Unfortunately,  the  Program  Manager  may  not  immediately  realize  that 
the  communication  process  has  broken  down.  This  is  especially  criti- 
cal for  new  program  initiatives  where  short  time  delays  may  mean 
missing  the  budget  cycle  for  at  least  another  year.  It  is  therefore 
important  that  the  Program  Manager  establish  and  maintain  good 
working  relations  at  all  levels  in  the  hierarchy.  He  must  be  astute 
enough  to  recognize  potential  "bottlenecks"  early  and  determine  alter- 
native communication  paths,  if  necessary  to  avoid  delays. 

5.2  Funding  Considerations 

Breaking  into  the  budget  cycle  is  a potential  pitfall  that  will 
plague  every  Program  Manager.  The  time  delays  inherent  in  the  Planning, 
Programming  and  Budgeting  System  were  discussed  in  section  2.1  of  this 
report.  The  Program  Manager  must  get  his  funding  requirements  into 
the  PPB3  cycle  at  least  29  months  prior  to  the  time  actually  needed. 
Failure  to  do  this  can  result  in  delaying  the  program  for  a year  or 
more.  Hence,  the  Program  Manager  must  develop  a good  working  relation 
with  the  Budget  people  and  must  make  sure  that  he  is  responsive  to 
their  timing  requirements  for  budget  formulation. 

i 
i 
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5.3  Concept  Formulation  Authorization  and  Funding 
A prerequisite  for  starting  the  Concept  Formulation  Phase  of  a 
program  is  the  issuance  of  an  Operational  Requirement  (OR)  by  01? NAV . 

This  in  itself  can  be  a source  of  some  controversy  and  can  l^ml  to  a 
"chicken- egg"  situation.  Normally , an  OR  is  generated  by  the  user 
(OPNAV)  in  response  to  a definite  operational  need  . The  NAVMat/SYSCOMS 
respond  to  the  OR  with  a Development  Proposal  (DP)  which  drawn  on 
the  existing  technology  base  and  identifies  a broad  range  of  system 
alternatives  which  address  the  operational  need.  There  is  aniilher 
school  of  thought,  however,  which  advocates  evolving  technoloKV  as  the 
primary  motivation  for  establishment  of  an  OR.  In  this  school  of  thought, 
emphasis  is  placed  on  the  role  of  Exploratory  Development  in  loading 
to  Advanced  System  Concepts  (ASC's)1  and  the  logical  transit! mving  of 
an  Exploratory  Development  Program  into  Advanced  Development  (after  all, 
an  OR  is  needed  to  "keep  the  work  going").  No  doubt,  outputs  | rom  the 
Exploratory  Development  Program  are  important  in  establishing  i he  tech- 
nology base  to  support  new  system  concepts  - but,  one  must  be  eareful 
that  these  outputs  do  not  become  "solutions  looking  for  a problem". 

This  potential  controversy  over  the  OR  can  create  adversary  ■ « lationships 
in  the  NAVMAT/SYSCOM/Laboratory  organizations  and  can  lead  to  blocked 
communication  channels  (as  mentioned  in  section  5.1).  The  S\;.tOM  Program 
Manager  must  develop  good  working  relations  with  the  laboratoi  |<>s,  NAVMAT, 
and  OPNAV  and  must  help  resolve  potential  controversies  before  they 
become  too  serious. 


^The  author's  experience  has  led  him  to  understand  that  tlm  ASC's 
are  used  primarily  in  the  planning  process  to  identify  possible  new 
starts  for  1 to  5 years  subsequent  to  the  budget  year. 


5-4 


f 


s 


i 

j 


F 


i 

i 


" ^ — • 1.1114.I.J  IUII..WIIHI  11 

I 

Related  to  the  above  discussion  of  the  OR  and  to  the  earlier  dis- 
cussion of  layering  (see  section  5.1),  is  the  Development  Proposal  (DP) 
requirements.  Different  offices  in  the  SYSCOMS,  NAVMAT  and  OPNAV  have 
different  ideas  of  what  constitutes  an  acceptable  DP.  The  instructions 
are  quite  clear  (see  section  3.3.1)  that  the  DP  is ’a  20-page  summary 
document  which  responds  to  the  OR  and  establishes  dialogue  with  OPNAV 
to  authorize  Concept  Formulation.  Yet,  there  are  offices  that  insist 
the  DP  should  be  many  volumes  and,  in  essence,  should  include  the  de- 
tailed work  that  is  being  proposed  for  Concept  Formulation  work.  Again, 
a "chicken-egg"  situation  and  adversarial  relationships  can  develop. 

1 

That  is* "you  can't  get  funding  to  do  Concept  Formulation  because  you 
haven't  done  Concept  Formulation".  The  author  believes  this  kind  of 
"bureaucratic  bottleneck"  is  a throw-back  to  the  old  way  (i.e.,  the 
GOR,  TSOR,  PTA,  ADO,  SOR,  TDP  methodology)  and  shows  a lack  of  under- 
standing (or  acceptance)  of  the  new  (OR,  DP,  NDCP,  DCP)  methodology  by 
some  pockets  of  resistance  to  change.  -A  similar  argument  to  the  above 
holds  for  the  NDCP,  which  is  OPNAV' s response  to  the  DP  authorizing  and 
identifying  funds  for  the  Concept  Formulation  Phase.  Again,  the  Program  j 

Manager  must  be  aware  of  these  potential  pitfalls  and  adapt  accordingly.  j 

Common  sense  must  be  used  in  tailoring  the  directives  for  the  OR,  DP 
and  NDCP  to  the  particular  program  situation.  Once  again,  the  working 
relation  with  the  people  at  all  levels  (i.e.,  in  the  laboratories,  SYSCOMS, 

NAVMAT  and  OPNAV)  is  all-important  in  preventing  potential  problems  from 
occurring. 
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4.  Preparation  for  DSARC  I 

The  whole  Concept  Formulation  effort  is  slanted  towards  prepara- 
tion  for  DSARC  1.  The  primary  document  generated  for  this  purpose  is 
the  DCP.  Actually,  the  DP,  NDCP  and  DCP  are  all  basically  the  same 
format  but  address  different  aspects  of  the  program.  The  NDCP  forms 
the  basis  for  the "DCP.  The  Program  Manager  must  make  sure  that 
adequate  backup  for  the  DCP  was  prepared  during  Concept  Formulation 
(i.e.  make  sure  the  homework  was  properly  done).  This  backup  includes 
identification  of  all  reasonable  alternatives  (including  foreign 
systems  and  modifications  to  existing  systems)  with  tradeoff  analyses 
to  show  why  a particular  alternative  was  selected  or  discarded.  It 
also  includes  detailed  plans  for  validation  including  identification 
of  risk  areas  and  plans  for  risk  elimination  with  fallback  positions. 

Preliminary  Design- to- Cost  and  Life- Cycle- Cost  goals  must  be  developed 
and  critical  support  requirements  must  be  identified.  Section  3 
identifies  in  more  detail  the  main  activities  and  outputs  that  must  occur 
during  Concept  Formulation.  The  above  items  are  called  out  for  special 
attention  by  the  Program  Manager  in  preparing  for  DSARC  I. 

While  the  Program  Manager  must  make  sure  his  homework  is  done  during 
Concept  Formulation,  he  muse  be  careful  not  to  make  the  DCP  thresholds 
too  tight.  He  will  have  to  live  with  them.  The  thresholds  should  be 
challenging--  but  achievable,  and  should  be  resonable  enough  to  provide 
the  Program  Manager  the  flexibility  needed  to  "manage  his  program" 
without  constant  intervention  from  the  SECDEF  level. 

Section  4 shows  a time-line  of  events  leading  up  to  DSARC  1. 

The  Program  Manager  must  coordinate  with  the  OPNAV  Sponsor/Coordinator 
and  NAVMAT  Coordinator  at  each  step  of  the  way  and  make  sure  that  the 
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outputs  from  Concept  Formulation  are  ready  to  support  each  review  along 
the  way.  Of  special  importance  is  the  series  of  briefings  for  the 
Office  of  the  Secretary  of  the  Navy  (OSN),  DDR&E  Staff,  DSARC  Principals' 
Stuff  and  DSARC  Support  Groups  immediately  prior  to  the  Scheduled  DSARC 
meeting.  These  briefings  can  help  make  the  DSARC  1 go  more  smoothly. 
Inadequate  coordination  and/or  briefings  along  the  way  can  lead  to 
problems  at  the  DSARC  meeting. 


6.  Conclusions  and  Recommendations 

This  Individual  Study  Project  has  served  its  primary  purpose  of 
allowing  the  author  to  probe  deeper  into  the  Acquisition  Management 
System  within  the  Department  of  ;he  Navy,  with  particular  emphasis  on 
procedures,  approval  cycles  and  documentation  requirements  leading  up  to* 
the  Program  Initiation  decision  for  a major  systems  program.  Some  atten- 
tion was  given  to  how  one  breaks  into  the  budget  cycle.  Detailed  acti- 
vities that  should  normally  occur  during  the  Concept  Formulation  Phase 
as  well  as  the  key  documentation  outputs  were  identified.  Finally,  some 
potential  problem  areas  that  might  occur  en  route  to  the  Program  Initia- 
tion decision  were  identified  and  discussed. 

The  salient  conclusions  and  recommendations  from  the  study  are  as 
follows: 

1.  The  DOD/Navy  organization  and  Acquisition  System  is 
extremely  complex.  This  leads  to  potential  problem 
areas  due  to  layering  effects  and  communication  break- 
downs. It  is  mandatory  that  anyone  concerned  with 
initiation  of  a new  program  develop  good  working 
relations  with  the  laboratories,  Syscoms,  NAVMAT  and 
OPNAV  at  all  levels  if  they  are  to  be  effective.  It 
is  the  informal  organization  which  will  get  the  work 
done  and  through  which  communication  problems  can  be 
resolved  before  they  become  too  serious. 

2.  The  Planning,  Programming  and  Budgeting  System  (PPBS) 
and  the  DCP/DSARC  Process  are  central  to  the  DOD/Navy 
Acquisition  System.  It  is  mandatory  that  anyone  concerned 
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with  initiation  of  a new  program  learn  the 
"system",  as  one  must  operate  within  it*  if  he 
is  to  be  effective. 

3.  Breaking  into  the  budget  cycle  can  be  especially 
difficult  for  a new  program.  The  PPBS  cycle  has 

a built-in  delay  of  about  21  months  between  the  input  j 

i 

to  the  planning  cycle  and  the  submission  of  the 
President's  Budget  to  Congress.  One  must  be  attuned 
to  the  timing  of  the  PPBS  cycles  and  the  Service 

Budget  Department's  call  for  budget  inputs.  New  ' 

program  funding  requirements  should  be  submitted  in  • | 

! , 

the  PCM  at  least  29  months  before  the  money  is  actually  i 

needed  for  obligation. 

4.  The  Concept  Formulation  Phase  established  a System 
Functional  Baseline,  identifies  critical  risk  areas 
and  develops  the  detailed  information  for  DSARC  1. 

Alternatives  considered  must  include  foreign  systems 
and  modifications  to  existing  systems  as  well  as  new 
systems.  The  primary  decision-making  output  document 
is  the  DCP.  All  other  information  provides  backup  for 
the  DCP.  One  must  make  certain  that  all  the  "homework" 
for  DSARC  I is  done  during  Concept  Formulation. 

5.  The  DCP  Thresholds  will  determine  the  degree  of  freedom 
within  which  one  can  manage  the  program.  Therefore, 
care  must  be  taken  not  to  make  the  thresholds  too 
tight  or  too  unreasonable.  Consequently,  the  DCP 

thresholds  should  be  challenging  but  attainable.  1 
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6.  A series  of  high-level  briefings  is  required  prior 
to  DSARC  I*  within  the  Navy  and  to  the  DSARC  Princi- 
pal1 s Staff.  These  briefings  can  be  very  helpful 
for  the  communication  process  and  if  properly 
done  can  lay  the  groundwork  for  a smooth  DSARC  I 
meeting.  Therefore,  one  should  adequately  prepare 
for  and  develop  a strategy  for  these  briefings. 
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Navy  Research  (6.1)  programs  are  grouped  into  two  program  elements 
in  the  five-year  defense  plan.  Program  Element  61152N  applies  to  In- 
House  Laboratory  Independent  Research  and  Program  Element  61153N  entitled 
Defense  Research  Sciences  has  fourteen  sub- elements.  These  are  summarized 
as  follows: 


Program  Element 
61152N 

61153N 

-11 

-12 

-13 

-14 

t 

-21 

-22 

-23 

-24 

-31 

-32 

-33 

-34 

-41 


Description  . 

In-House  Laboratory  Independent 
Research 

Defense  Research  Sciences 

General  Physics 

Nuclear  Physics 

Chemistry 

Mathematics 

Electronics 

Materials 

Mechanics 

Energy  Conversion 

Oceanography 

Terrestial  Sciences 

Atmospheric  Sciences 

Astronomy  and  Astrophysics 

Biological  and  Medical 
Sciences 

Behavioral  and  Social 
Sciences 
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Navy  Exploratory  Development  (6.2)  programs  are  grouped  into 
nineteen  Program  Elements  in  the  Five-Year  Defense  Plan,  as  sumraarixt'd 
below. 


Program  Element 

Description  (Technology  Areas) 

627 11 N 

Undersea  Target  Surveillance 

62712N 

Surface/Aero  Space  Target  Surveillance 

62721N 

Command  & Control 

62331N 

Missile  Propulsion 

62332N 

Strike  Warfare  Weaponry 

62633N 

Undersea  Warfare  Weaponry 

6273AN 

Countermeasures 

622A IN 

Aircraft 

62542N 

Nuclear  Propulsion 

62543N 

Ships,  Subs  and  Boats 

62758N 

Biomedical  Technology 

62759N 

Ocean  and  Atmospheric  Support  Technology 

62760N 

Logistics  Technology 

62761N 

Materials 

62762N 

Electronic  Devices 

62763N 

Human  Resources 

62764N 

Chemical/Biological  Defense  Technology 

62765N 

Energy  and  Environmental  Protection 

62766N 

Laboratory  Independent  Exploratory  hovel . 

L_ 
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APPENDIX  B 


DEVELOPMENT  PROPOSAL  (DP)  CONTENTS 


This  appendix  is  a copy  of  enclosure  (3)  to  OPNAVINST  5000.42, 
is  reproduced  here  for  convenient  reference. 


t 


OPNAVINST  5000.42 
1 June  1974 


SECTION  IV 

DEVELOPMENT  PROPOSAL  (DP)  CONTENTS 
PROGRAM  TITLE 


I.  Background 

State  need  extracted  from  the  Operational 
Requirement  (OR) . Expand  if  appropriate.  State 
need  in  positive  terms.  Do  not  state  deficiencies 
in  current  operations,  tactics,  or  systems.  Indi- 
cate need  in  appropriate  time  frame.  Use  simple, 
terse,  concise  language.  Do  not  use  verbose 
"boiler-plate"  descriptions. 

II.  Issues 

Initiate  conceptual,  advanced  or  engineering  develop- 
ment. 

Point-out  other  key  issues  (joint  programs,  costs, 
schedules.  Congressional  impact  or  actions,  changes  in 
threat,  etc.) 

III.  Requirement  and. Program  Objectives 

State  how  recommended  alternative (s)  and/or 
objective (s)  satisfy (ies)  the  operational  need. 

IV,  Program  Alternatives 

Describe  alternative  approaches  investigated. 

Indicate  relevant,  previous  test  results.  Show 
comparative  advantages/disadvantages  of  each  signif- 
icant or  reasonable  alternative  considered.  Describe 
logistic  support  approaches,  identifying  significant 
impact  on  personnel  skill  levels  and  numbers.  Pro- 
vide rationale  for  selected  proposed  approach. 

V.  Effectiveness  and  Cost  Comparison  of  Alternatives 

Indicate  as  applicable:  Estimated  development 

cost  and  cost-time  profile?  estimated  unit  cost  of 
production  model  (design-to-cost) ; estimated  develop- 
ment/production schedules;  indicate  risks  of  failure 
with  respect  to  performance,  military  value,  cost  and 
schedule;  relation  to  Hi/Lo  mix  and  expected  utiliza- 
tion in  fleet  modernization  and  future  ship  and 
aircraft  classes/types/models?  estimated  degree  of 
relative  improvement  over  existing  systems. 


Enclosure  (3) 
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OPNAVINST  50QD-42 
1 June  1974 

VI.  Risks 

* List  and  explain  critical  performance  tests 
during  development.  Cite  uncertainties  to  be 
resolved,  including  relative  performance  risk, 
cost,  and  schedule  risks. 

VII.  Other  Factors 

Indicate  other  factors  which  might  be  important 
to  the  effective  introduction  of  this  system,  i.e., 
logistics,  training,  support,  environmental. impact. 

Indicate  other  on-going  or  proposed  related 
programs  and  the  interface  of  this  proposal  to 
other  programs.  Include  Navy,  Joint  Service,  Army, 
and  Air  Force  programs/projects. 

VIII.  The  Development  Plan(s)  Achievement  Milestones 
and  Thresholds  " ~ 

Indicate  RDT&E  milestone  schedule  and  recommend 
category  (6.3,  6.4,  or  production).  Critical  logistics 
milestones  (manual,  test  equipment  verification,  and 
test  leading  to  approval  for  service  use)  shall  be 
included,  if  available. 

IX.  Approval 

Each  DP  will  contain  an  approval/disapproval 
page(s)  which  will  conform  as  near  as  practical  to 
a DCP  approval/disapproval  page(s)  form. 
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Program-Initiation  DCP/PM. 

1.  A program-initiation  DCP  or  PM  should  demonstrate  that: 

a.  T'.:e  system  satisfies  a real  military  need  better  than 
feasible  alternat  .ve  systems/  is  worth  its  cost,  and  if  of  sufficient 
priority  to  warrant  funding  within  overall  fiscal  constraints. 

b.  Mission  Profile  (s)  and  performance  envelope (s)  are 
defined  adequately  and  based  upon  sound  military,  technical,  logistics,  1/ 
and  economic  objectives. 

c.  Preliminary  total  life  cycle  cost  and  schedule  estimates 
are  realistic  and  acceptable. 

d.  All  significant  military,  technical,  and  business  risks 
have  been  identified  and  resolution  actions  are  well  planned,  sound, 
and  acceptable. 

e.  The  management  approach,  program  plan  and  overall 
acquisition  strategy  are  sound. 

f.  Cost,  schedule,  and  characteristics  thresholds  are 
well-defined,  provide  flexibility  for  accomplishing  appropriate 
trade-offs  before  full-scale  development  starts,  and  will  cause 
significant  problems  to  surface  for  management  attention. 

g.  The  environmental  impact  is  minimized  and  acceptable. 

h.  A broad  general  plan  for  integrated  logistics  support 

has  been  accomplished  with  any  special  problems  noted  therein.  1/ 

2.  The  general  organization  of  the  DCP  or  PM  should  succes- 
sively: 

a.  Identify  the  threat  and  cite  appropriate  analytic 

sources. 

b.  Describe  and  substantiate  the  operational  need. 

c.  Describe  broad  performance  objectives  and  substantiate 
that  these  proposed  objectives  correspond  well  to  the  operational  need. 

d.  Summarize  the  expected  effectiveness  and  costs  of 
alternatives,  plus  principal  determining  factors,  and  compare  the 
alternatives  with  the  proposed  program. 

e.  Identify  critical  questions  and  areas  of  risk  to  be 
resolved  by  test  and  evaluation. 

f.  Present  the  plan  for  executing  the  first  program  phase 
including  schedules  and  milestones.  State  objectives  and  principal 
consideration.  Provide  for: 

(1)  Resolution  of  issues, 

(2)  Investigation  of  appropriate  risk  areas  through 
test  and  evaluation. 

(3)  Contingency  (fall-back)  actions. 


1/  change  #19 


NE-15 


1 


g.  Propose  cost  (including  design-to-cost),  schedule,  and 
performance  thresholds  for  the  program  first  phase. 

h.  Outline  the  planned  overall  acquisition  strategy. 

i.  Describe  the  management  structure  and  planned  manage- 
ment system.  Assign  responsibilities  as  explicitly  and  unambiguously 
as  practical. 


* 3.  In  creating  a proposed  DCP  or  PM  outline,  consider  both: 

a.  Whether  material  referenced  in  a section  will  have  been 
presented  in  an  earlier  section,  i.e.,  the  sequence  in  which  relevant 
material  should  be  presented  and  read. 

b.  The  practicality  of  assigning  sections  to  individuals 
for  preparation  and  correction  with  short  deadlines. 

4.  Avoid  overcommitment.  The  purpose  of  a post-initiation 
phase  is  to  assure  that  the  proposed  program  is  the  optimal  program 
to  enter  into  full-scale  development.  A strong  prejudice  in  favor 
of  a particular  problem  solution  based  upon  inadequate  investigation 
is  most  undesirable. 
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APPENDIX  D 

OUTLINE  FOR  PREPARATION  OF  A DCP 
This  appendix  is  a copy  of  pages  NE-10  through  NE- 14  (i.e.  Tab 
C to  Appendix  NE)  of  the  Navy  Programming  Manual  (3).  The  material  is 
reproduced  here  for  ease  of  reference. 


VI.  Risks . (Cont'd) 


e For  each  risk  identify  the  impact  on  system  performance  if  the 
component  or  technology  advance  falls  short  of  expectation. 

0 Characterize  the  degree  of  risk  in  terms  of  the  technical 

achievement,  operational  and  logistics  implications,  cost  1/ 
and  schedule. 

• State  pertinent  available  data  and  delineate  the  data  require- 
ments . 

0 Confidence  or  lack  thereof  in  the  latest  cost  estimates  to 
complete. 

0 Summarize  in  a few  sentences  the  overall  risks;  technological 
and  economic. 

VII.  Test  and  Evaluation 

° Critical  questions  and  areas  of  risk  to  be  or  remaining  to  be 
resolved  by  test. 

0 Developmental  Test  and  Evaluation.  Summarize  results  of 

developmental  testing  to  date  and  plans  for  additional  testing. 
Identify  testing  agency,  location  of  tests,  and  dates  of  tests. 

0 Operational  Test  and  Evaluation.  Summarize  results  of 

operational  testing  to  date  and  plans  for  additional  testing. 
Identify  testing  agency,  location  of  tests,  and  dates  of  tests. 
Indicate  the  degree  to  which  the  item  tested  is  representative 
of  the  expected  production  item. 

a System  Characteristics.  Show  performance  objectives  and 

demonstrated  performance  to  date.  Indicate  whether  performance 
demonstrated  by  developmental  or  operational  testing. 

VIII.  Other  Factors . 


What  other  factors  are  important  to  the  effective  fielding  of  this 
military  system;  e.g.,  logistics  considerations,  special  training,  1/ 
new  schools,  increased  personnel  skills,  new  maintenance  facili- 
ties, or  special  test  facilities  and  equipment?  The  probable 

impact  of  the  system  on  the  environment  are  assessed  in  this 
section. 

* The  Development  Plan  f*?)  Achievement  Milestones  and  Thresholds. 

Program  Development  Plan,  show  for  each  relevant  option: 

0 Program. 

° Major  Program  Elements. 

0 Fiscal  Summary  related  to  the  Elements. 

° Action  Responsibilities. 

0 Achievement  Milestones. 

° Threshold  Events. 

°-  Developmental  and  Operational  Test  and  Evaluation. 
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Figure  1»  Program  Development  Plan(s)  Milestones* 
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X.  Resource  Annex. 


The  DCP  text  in  citing  the  resource  annex,  a sample  of  which  is 
shown  on  next  page,  should  state  explicitly  what  costs  for  each 
alternative  are  not  now  in  the  FYDP.  Additionally,  cost  estimates 

should  indicate  the  base  FY  dollars  used  and  approved  rate  of 
escalation. 

XI.  Overall  Evaluation  of  Options. 

*.  Assess  costs  and  benefits. 

° Alternative  appraisal. 

• Basis  for  action  decision. 

XII.  Management. 

• Management  method  and  organization. 

• Extent  of  authority  provided  manager. 

° Dependence  of  manager  on  external  support. 

• Reporting  and  validating  procedure. 

XIII.  Security. 

• Identify  which  parts  oi  the  program,  process,  capability,  and 
element  are  classified  as  well  as  those  elements  which  are 
unclassified. 

• Identify  how  the  classification  of  the  several  elements  change 
with  the  different  time  periods  of  development  and  deployment. 
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XIV.  Next  DCP . 


• State  when  this  DCP  should  be  revised  and  why. 


XV.  Recommendations . 


• If  SECDEF  action  is  or  may  be  warranted  in  the  next  month  or  two, 
state  exactly  what  he  should  decide  and  why,  which  option  for 
what  reasons. 

• State  when  the  next  decision  after  the  above  is  expected. 

• State  what  information  not  now  available  will  be  needed  to  make 
the  next  decision. 
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